Closed
Bug 1208102
Opened 9 years ago
Closed 9 years ago
Treeherder is submitting the classification dates to ElasticSearch with the wrong timezone
Categories
(Tree Management :: Treeherder, defect, P2)
Tree Management
Treeherder
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: emorley, Assigned: emorley)
References
Details
Attachments
(1 file)
On:
http://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1207774&startday=2015-09-23&endday=2015-09-23&tree=all
There are both entries from 23rd and 24th Sept.
Must be more timezone related fun, sigh.
Assignee | ||
Comment 2•9 years ago
|
||
(In reply to Ed Morley [:emorley] from comment #1)
> This will likely be fixed by bug 1209339.
Hmm or not.
So for this page:
http://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1207774&startday=2015-09-23&endday=2015-09-23&tree=all
Classifications are shown from midday 23rd sept through to almost 8am 24th sept, so this must be a pacific vs UTC timezone issue.
The API call for that page is:
http://brasstacks.mozilla.com/orangefactor/api/bybug?startday=2015-09-23&endday=2015-09-23&bugid=1207774
Picking the last occurrence:
* Job start time as shown in the OF UI: 24 Sep 2015, 07:38 UTC
* Job start time shown in the raw log: 1443080294.8 -> 09/24/2015 @ 7:38am (UTC)
From the OF API response:
{
"buildtype": "debug",
"branch": "try",
"treeherder_job_id": 11835104,
"date": "2015-09-23",
"bug": "1207774",
"machinename": "t-w864-ix-040",
"classification_time": "1443391353",
"platform": "windows8-64",
"starttime": "1443080294",
"test": "mochitest-browser-chrome-2",
"revision": "a96306a84fc8"
}
classification_time -> 09/27/2015 @ 10:02pm (UTC)
starttime -> matches what the raw log says: 09/24/2015 @ 7:38am (UTC)
So basically "date" is wrong.
This is confirmed by looking at the raw data for that classification in ElasticSearch:
{
"buildtype": "debug",
"treeherder_job_id": 11835104,
"os": "windows8-64",
"tree": "try",
"who": "SNIP",
"buildname": "Windows 8 64-bit try debug test mochitest-browser-chrome-2",
"date": "2015-09-23",
"bug": "1207774",
"machinename": "t-w864-ix-040",
"rev": "a96306a84fc8",
"starttime": "1443080294",
"timestamp": "1443391353",
"type": "Mochitest Browser Chrome"
},
So Treeherder is in fact submitting the 'date' field in Pacific, not UTC after all, even though the rabbitmq timezone is UTC:
[emorley@treeherder-rabbitmq1.private.scl3 ~]$ date
Tue Sep 29 11:17:56 UTC 2015
Status: NEW → ASSIGNED
Component: OrangeFactor → Treeherder
Priority: -- → P2
Summary: Results from the next day appearing in single page view → Treeherder is submitting the classification dates to ElasticSearch with the wrong timezone
Assignee | ||
Comment 3•9 years ago
|
||
Hmm:
[emorley@treeherder-rabbitmq1.private.scl3 treeherder-service]$ date
Tue Sep 29 11:40:50 UTC 2015
[emorley@treeherder-rabbitmq1.private.scl3 ~]$ cat /etc/sysconfig/clock
ZONE="UTC"
[emorley@treeherder-rabbitmq1.private.scl3 ~]$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 23 May 30 2014 /etc/localtime -> /usr/share/zoneinfo/UTC
[emorley@treeherder-rabbitmq1.private.scl3 treeherder-service]$ ../venv/bin/python ./manage.py shell
>>> import datetime
>>> datetime.datetime.today()
datetime.datetime(2015, 9, 29, 4, 37, 11, 902909)
[emorley@treeherder-rabbitmq1.private.scl3 treeherder-service]$ ../venv/bin/python
>>> import datetime
>>> datetime.datetime.today()
datetime.datetime(2015, 9, 29, 11, 39, 46, 530121)
So it looks like the Django python environment has overridden the timezone datetime uses, even though the Django docs imply that the settings/base.py line of:
TIME_ZONE = "America/Los_Angeles"
...should only affect internal Django functionality.
I've found this that shows that Django does mess with the environment variable TZ, which is presumably why datetime behaviour changes:
https://github.com/django/django/blob/593c9eb6608c660f9e2c1ade227670539ececd8e/django/conf/__init__.py#L119-L129
Either way, Treeherder should always have been using utcfromtimestamp() not fromtimestamp() (the latter is a big footgun, why it's called that in the std python library I don't know; localfromtimestamp() would be much more useful) - so let's fix that. In another bug we can look at changing TIME_ZONE in settings/base.py to UTC, but there might be wider implications so not going to do that here.
Assignee | ||
Comment 4•9 years ago
|
||
Attachment #8667231 -
Flags: review?(mdoglio)
Updated•9 years ago
|
Attachment #8667231 -
Flags: review?(mdoglio) → review+
Comment 5•9 years ago
|
||
Commit pushed to master at https://github.com/mozilla/treeherder
https://github.com/mozilla/treeherder/commit/28d5708d7f285e82ca03b5c97608daa8d0c42cb2
Bug 1208102 - Submit the job start time date as UTC to ElasticSearch
Since `.fromtimestamp()` is being overridden by Django's TIME_ZONE and
so uses Pacific Time, even though rabbitmq's server time is UTC.
Assignee | ||
Updated•9 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•