11–20 of 37 posts
I'm quite curious if local churches will follow along with the change. I know Jews wouldn't, and I doubt Muslims would, but I don't think there are any Jews there anyway, not sure about Muslims.
I would not want to be a calendar software developer right now.
It's cases like this that show that you should use a proper timezone library in your code. Too often I see websites where the timezone field is given as "+/- X from GMT". Just store everything in UTC, and use tzdata fields (e.g. "Europe/London") to convert to something nice to show the user, and People Cleverer Than You™ will make sure everything works.
Suppose you are writing a appointment tracking system, and, at some point before the olson tz database has been updated with this change, the user in the Samoa timezone creates an future appointment for Jun 2, 2012. That would be stored in UTC.
Now, you upgrade the olson TZ database file on your server to a newer version, which incorporates the Somoa tz change. Now, without any user input, the appointment is suddenly on Jun 3, 2012! (because the same UTC date, with the updated TZ database, is Jun 3, 2012)
Is that what a user would have expected if they created the appointment for Jun 2, 2012? I would say no. But that said, what if the appointment was for Dec 30 2011? That date no longer exists, so it would have be pushed ahead automatically.
Conclusion: time zones are hard
It's cases like this that show that you should use a proper timezone library in your code. Too often I see websites where the timezone field is given as "+/- X from GMT". Just store everything in UTC, and use tzdata fields (e.g. "Europe/London") to convert to something nice to show the user, and People Cleverer Than You™ will make sure everything works.
Storing everything in UTC is a huge improvement, but is still an imperfect solution because the Tz database changes over time. Suppose you are writing a appointment tracking system, and, at some point before the olson tz database has been updated with this change, the user in the Samoa timezone creates an future appointment for Jun 2, 2012. That would be stored in UTC. Now, you upgrade the olson TZ database file on y…
Earlier quoted context omitted.
Storing everything in UTC is a huge improvement, but is still an imperfect solution because the Tz database changes over time. Suppose you are writing a appointment tracking system, and, at some point before the olson tz database has been updated with this change, the user in the Samoa timezone creates an future appointment for Jun 2, 2012. That would be stored in UTC. Now, you upgrade the olson TZ database file on y…
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?
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
Earlier quoted context omitted.
Storing everything in UTC is a huge improvement, but is still an imperfect solution because the Tz database changes over time. Suppose you are writing a appointment tracking system, and, at some point before the olson tz database has been updated with this change, the user in the Samoa timezone creates an future appointment for Jun 2, 2012. That would be stored in UTC. Now, you upgrade the olson TZ database file on y…
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?
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.
It's cases like this that show that you should use a proper timezone library in your code. Too often I see websites where the timezone field is given as "+/- X from GMT". Just store everything in UTC, and use tzdata fields (e.g. "Europe/London") to convert to something nice to show the user, and People Cleverer Than You™ will make sure everything works.
Storing everything in UTC is a huge improvement, but is still an imperfect solution because the Tz database changes over time. Suppose you are writing a appointment tracking system, and, at some point before the olson tz database has been updated with this change, the user in the Samoa timezone creates an future appointment for Jun 2, 2012. That would be stored in UTC. Now, you upgrade the olson TZ database file on y…
I would not want to be a calendar software developer right now.