Hacker News new | ask | show | jobs
by tedmiston 3594 days ago
I've been happily using django.utils.timezone for a while now and doing everything on the backend in UTC. For any user-facing timestamps, to some degree I'd rather keep that in the front end and a separate concern from my API.

Not saying storing user timezone and converting on the backend is bad; but this is simpler when localized timestamps aren't a core part of my app.
1 comments
jsmeaton 3594 days ago
Yes, always work in UTC. But you could use this library to convert user provided naive datetimes to UTC, and datetimes coming from the database into localised datetimes. Converting from/to timezones other than UTC in Django isn't as nice as it could be.
link
masklinn 3594 days ago
No, don't always work in UTC.

If a Samoan user told you to record an event for January 1st 2012 on January 1st 2011, if you stored the date in UTC would have reminded them on January 2nd 2012 (all local).

Because in May 2011 Samoa announced they were going to skip a local day and move across the international date line. So 2011-12-30T09:00:00 UTC was 2011-12-29T23:00:00 Pacific/Apia, but 2011-12-30T10:00:00 UTC was 2011-12-31T00:00:00 Pacific/Apia.

link
jsmeaton 3594 days ago
Wow, that's a really interesting case. I guess the same thing would happen whenever an offset was adjusted after you store a value in UTC intended for another timezone. I don't think this is even supported by Django - all times are converted to UTC on entry to the database.
link
masklinn 3593 days ago
> Wow, that's a really interesting case. I guess the same thing would happen whenever an offset was adjusted after you store a value in UTC intended for another timezone.

Yep, or if a DST change was added or rescinded (which can happen on surprisingly short orders, many governments love fucking up with DST, this year 2016 we got an infirmation of Egyptian DST with 3 days lead time).

link
tedmiston 3594 days ago
That's very interesting. I wonder if the popular datetime libraries issued a patch for this case?
link
masklinn 3593 days ago
tz libraries shipped a new version for the tzdata update, as they do more or less every time the database is updated (monthly or so). 9 months lead time is actually pretty good, consider: April 29th the Egyptian government announced they'd go on DST on July 7th, with no further information until June 27th when Parliament proposed to abolish DST and passed a (apparently non-binding) vote for that on June 28th, following which the Egyptian government announced they wouldn't go on DST after all on July 4th.
link
tedmiston 3593 days ago
It sounds like I should be updating my tz dependencies more often :o
link