[masklinn]

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.

[jsmeaton]

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.

[masklinn]

> 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).

[tedmiston]

That's very interesting. I wonder if the popular datetime libraries issued a patch for this case?

[masklinn]

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.

[tedmiston]

It sounds like I should be updating my tz dependencies more often :o