[natrius]

My assumption was that the TZ database noted when changes in time zones happened so there was always an accurate one-to-one mapping between a Unix time and a time in each time zone. Adding 2012's time zone information wouldn't override 2010's. Is this incorrect?

[rmc]

> there was always an accurate one-to-one mapping between a Unix time and a time in each time zone

That's not true in general. When the "clocks go backwards", there are two 1:30ams on that morning.

The bug this comment is refering to, is where you convert from local to UTC as soon as the user enters the datetime, and then use that from then on. Since the "local to UTC" conversion might change between now and the date, as the tzdata time is updated, you might get this bug.

[mikeash]

It seems to me that it's impossible to solve this bug in the general case. If the user enters March 15, 2012 before the switch, should that become March 16, 2012 after the switch, or stay March 15? Either scenario could be correct depending on the intent of the date. Messy.

[elefont2]

it does, but you cannot predict future legislation.

In 2010, you may not yet know that the timezones will change in 2012, but you might still need to store a 2012 date in your database.

So, the best you can do, if storing in UTC, is store that 2012 date using 2010 timezone rules, as you don't yet know what the 2012 time zone rules are going to be