Opened 8 years ago
Closed 8 years ago
#1065 closed defect (fixed)
Timestamps are not UTC
|Reported by:||Jonas Haraldsson||Owned by:|
All timestamps are generated from localtime (
datetime.datetime.now()) and the API displays them as UTC ("2014-12-11T13:03:59.261590+00:00") (#1023) which will be off by n hours depending on which timezone the server is in.
Probably best fixed by changing timestamp generation to use
Change History (5)
comment:1 by , 8 years ago
comment:2 by , 8 years ago
comment:3 by , 8 years ago
|Status:||new → accepted|
Okay this was done based on the assumption that everything stored and retrieved from the database was UTC and simply lacked the timezone information. It turns out this is actually incorrect as suggested. It would seem what is needed is:
1) a migration for all DateTime fields to be timezone aware
2) remove code which adds the timezone for the API
This causes an issue though as we support SQLite in MediaGoblin and SQLite doesn't support timezone aware DateTime fields so I'm not too sure what to do about this. Postgres it would seem has made our lives easier when the user has used that as
All timezone-aware dates and times are stored internally in UTC. They are converted to local time in the zone specified by the timezone configuration parameter before being displayed to the client.
comment:4 by , 8 years ago
|Status:||accepted → in_progress|
comment:5 by , 8 years ago
|Status:||in_progress → closed|
This is now fixed as of d705f3b7. You should be able to run the migration for existing timestamps to change to UTC and all new timestamps will by default be created in the UTC timezone. Please re-open if you think this is still an issue.
Yes, I've seen this from Dianara. With Tsyesika's server I had a 1h difference, which matches this issue, considering we're in close TZ's.