Opened 9 years ago

Closed 9 years ago

#1065 closed defect (fixed)

Timestamps are not UTC

Reported by: Jonas Haraldsson Owned by:
Priority: major Milestone: 0.8.0
Component: programming Keywords:
Cc: JanKusanagi Parent Tickets:


All timestamps are generated from localtime ( 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 datetime.datetime.utcnow()

Change History (5)

comment:1 by JanKusanagi, 9 years ago

Cc: JanKusanagi added

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.

comment:2 by Jessica Tallon, 9 years ago

Milestone: 0.8.0

comment:3 by Jessica Tallon, 9 years ago

Status: newaccepted

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 Jessica Tallon, 9 years ago

Owner: set to Jessica Tallon
Status: acceptedin_progress

comment:5 by Jessica Tallon, 9 years ago

Owner: Jessica Tallon removed
Resolution: fixed
Status: in_progressclosed

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.

Note: See TracTickets for help on using tickets.