718958 - BuildID is shifted by one day before in Graph and Table tabs

Status: RESOLVED FIXED

(Socorro :: General, task)

Description

[Scoobidiver (away)]

See:
https://crash-stats.mozilla.com/report/list?range_value=7&range_unit=days&signature=js_GetIndexFromBytecode&version=Firefox%3A9.0.1
As sometimes these two tabs are used to determine regression ranges, they will be wrong.

Comment 1

[Robert Kaiser]

I don't see what the problem might be, everything looks correct to me. Can you be more specific?

Comment 2

[Scoobidiver (away)]

9.0.1 build ID is 20111220165912 while Graph and Table tabs report it's 2011121916.
I know that minutes and seconds are truncated in these tabs but the date is shifted by one day before.
If you try to determine regression ranges from the Table tab, what I do sometimes, they will be wrong.

Comment 3

[Robert Kaiser]

We never generate two releases in the same hour, not even betas, so the truncation is a non-issue.

In the URL you point to, in the "Table" tab, I see this:
Build ID 	Crashes 	Win 	Mac 	Lin
2011122716 	3 - 100.000% 	0 - 0.000% 	0 - 0.000% 	3 - 100.000%
2011122216 	1 - 100.000% 	0 - 0.000% 	0 - 0.000% 	1 - 100.000%
2011121916 	12510 - 100.000% 	12418 - 100.000% 	92 - 100.000% 	0 - 0.000% 

It took me some while but I think I see where you're coming from. We clearly didn't have that before, so maybe the UTC stuff plays a role here?

Comment 4

[[:jberkus] Josh Berkus]

Rob,

Instead of reformatting the buildid on the PHP side, just use the build_date() function on the database side:

build_date(build_numeric(build))

Comment 5

[Robert Helmer [:rhelmer]]

(In reply to [:jberkus] Josh Berkus from comment #4)
> Rob,
> 
> Instead of reformatting the buildid on the PHP side, just use the
> build_date() function on the database side:
> 
> build_date(build_numeric(build))

Hmm it's actually using reports.build_date already, and the way it's truncated *looks* ok (date_trunc('day', reports.build_date) AS build_date) .. will need to dig into this a bit more.

Josh is there a reason to switch from reports.build_date to reports.build  ?

Comment 6

[Robert Helmer [:rhelmer]]

(In reply to Robert Helmer [:rhelmer] from comment #5)
> (In reply to [:jberkus] Josh Berkus from comment #4)
> > Rob,
> > 
> > Instead of reformatting the buildid on the PHP side, just use the
> > build_date() function on the database side:
> > 
> > build_date(build_numeric(build))
> 
> Hmm it's actually using reports.build_date already, and the way it's
> truncated *looks* ok (date_trunc('day', reports.build_date) AS build_date)
> .. will need to dig into this a bit more.
> 
> Josh is there a reason to switch from reports.build_date to reports.build  ?

Comment 7

[Robert Helmer [:rhelmer]]

(In reply to Robert Helmer [:rhelmer] from comment #5)
> (In reply to [:jberkus] Josh Berkus from comment #4)
> > Rob,
> > 
> > Instead of reformatting the buildid on the PHP side, just use the
> > build_date() function on the database side:
> > 
> > build_date(build_numeric(build))
> 
> Hmm it's actually using reports.build_date already, and the way it's
> truncated *looks* ok (date_trunc('day', reports.build_date) AS build_date)
> .. will need to dig into this a bit more.
> 
> Josh is there a reason to switch from reports.build_date to reports.build  ?

Ah ok now I see what you're suggesting - this is such a simple and tiny fix on the PHP side I don't think we should uproot a significant amount of code for this. We will do it differently as we transition to a new frontend.

Comment 8

[Robert Helmer [:rhelmer]]

This is indeed a UTC bug, we can fix it by using gmdate instead of date (as far as I can tell).

brandon r? https://github.com/mozilla/socorro/pull/289

Comment 9

[Robert Kaiser]

(In reply to Robert Helmer [:rhelmer] from comment #8)
> This is indeed a UTC bug, we can fix it by using gmdate instead of date (as
> far as I can tell).

Hah, yes, gmdate is more correct than date now that we are using UTC, of course. I'd r+ if that counted. ;-)

Comment 10

[Scoobidiver (away)]

(In reply to Robert Helmer [:rhelmer] from comment #8)
> brandon r? https://github.com/mozilla/socorro/pull/289
Will this patch fix also the inconsistent build hour (see for instance https://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A12.0a1&query_search=signature&query_type=contains&reason_type=contains&date=01%2F22%2F2012%2008%3A00&range_value=7&range_unit=days&hang_type=any&process_type=any&do_query=1&signature=js%3A%3Amjit%3A%3AEnterMethodJIT%28JSContext*%2C%20js%3A%3AStackFrame*%2C%20void*%2C%20JS%3A%3AValue*%2C%20bool%29)?

Comment 11

[[github robot]]

Commit pushed to master at https://github.com/mozilla/socorro

https://github.com/mozilla/socorro/commit/1c407feed2a75cd08ae8de905d5f68b2a6c11480
Merge pull request #289 from rhelmer/bug718958-buildid-shifted

bug 718958 - consider build_date to be UTC

Comment 12

[Scoobidiver (away)]

See also bug 716679.

Comment 13

[Robert Helmer [:rhelmer]]

(In reply to Scoobidiver from comment #10)
> (In reply to Robert Helmer [:rhelmer] from comment #8)
> > brandon r? https://github.com/mozilla/socorro/pull/289
> Will this patch fix also the inconsistent build hour (see for instance
> https://crash-stats.mozilla.com/report/
> list?product=Firefox&version=Firefox%3A12.
> 0a1&query_search=signature&query_type=contains&reason_type=contains&date=01%2
> F22%2F2012%2008%3A00&range_value=7&range_unit=days&hang_type=any&process_type
> =any&do_query=1&signature=js%3A%3Amjit%3A%3AEnterMethodJIT%28JSContext*%2C%20
> js%3A%3AStackFrame*%2C%20void*%2C%20JS%3A%3AValue*%2C%20bool%29)?

It does now, yes. Thanks for pointing this out.

Comment 14

[Robert Helmer [:rhelmer]]

(In reply to Scoobidiver from comment #12)
> See also bug 716679.

Thanks, should be simple to adapt.