Australia is currently in an interesting week for time zones.
Up until a couple of years ago, Daylight Savings finished on the last Sunday in March. That’s when the clocks got put back to Standard Time, as the Australian summer ended. Last year though, this got extended by a week, until the first Sunday in April. A similar change was made in October, changing the start of Daylight Savings from the last weekend of October to the first weekend of October. We now have six months of summer instead of five (although weather-wise, it’s a lot more…)
That’s fine — most people have patched their machines happily, and don’t have a problem. My mobile phone is an old O2 XDA, running Windows Mobile 2003 (I once upgraded to a newer device, but a washing machine had an argument with it and won). Unfortunately, i don’t think there’s a patch for WM2003, and so this week my phone (and hence, my alarms) thinks that I’m an hour out.
It’s fine when I’m in Melbourne or Sydney — I can set the time zone to be Magadan (which is in Russia), and the problem goes away. All good — I don’t really care where my phone thinks I am, just so long as the time is right.
The problem is when I’m in Adelaide… Adelaide which is normally in GMT+0930 (yes, on the half-hour), but this week is still in GMT+1030. According to my mobile device, there is nowhere in the world that is GMT+1030 this week. So instead I’ve had to change my alarms to wake me up half an hour later, whilst I pretend I’m in Siberia. I recently learned that the Russian for “Bless You” (ie, that thing you say when someone sneezes) is “Bud Zdorov” (literally "Be Healthy”, and I apologise for the spelling. ‘Bud’ rhymes with ‘Good’). I’m not sure it’s quite enough to get me through though.
One day I plan to visit Kathmandu, where the time zone is on the quarter-hour. Then I can return to the normality of Adelaide’s half-hour time zone.
I’ve written about the pain of daylight savings before, particularly around the pain of storing datetime fields in a database. Today i read a post from Bart Duncan, recommending the use of datetimeoffset. I thoroughly agree with him, although I wonder how long it will be before people make this a priority.
This Post Has 6 Comments
What really makes me laugh, is Brisbane is actually half an hour BEHIND Adelaide. Yes, behind. Then when the time zone settings switch, Brisbane is suddenly half an hour in front.
I’d love to see the globe that these idiots who dream up the timezones use. On their map, every April, Australia must tilt 45 degrees anti-clockwise.
I feel your pain, Rob. Our main data-entry application here at work runs on WM2003 devices, and we’ve only gotten about half of it ported away from DataSets to POCOs. The result is that .NET does some weird timezone-shifting magic when the data moves from the device to the server, and dates that should be 12 midnight are stored as 1am (or 11pm depending on which “daylight saving witching week” you’re in at the time).
We were able to get a patch from the device vendor but not in time to roll out to every device by this week. Hopefully we’ll have the rest of the app ported by the time this happens again in spring!
The one I also love is Outlook. Ignoring daylight savings time… if I put an ‘all day event’ in Outlook and then change time zones, it suddenly thinks that my all-day event is across two days, starting at 2300/2330/0030/0100 depending on the travel.
Crazy… I want an option in Outlook that says “All day event, ignoring time zone”
Rob
Hey Rob
I agree on the time zone thing – UTC for the win. 🙂 Even if you do a local time-zone offset at the presentation level, the shenannigans that have been going on with time zones in the US, Australia and other parts of the world over the last 3 years have convinced me that DB time fields should *ALWAYS* be UTC-based. Adding in a table with current time-zone conversions, and a a function to convert the UTC time to the user’s locale should make it much easier to manage the impact of time-zone changes.
Hi Jeremy,
I’m actually sold on the idea of using datetimeoffset instead of UTC-time. SQL2008 definitely provides useful ways of converting from one timezone to another, but I don’t want to store the information about when daylight savings has switched.
Rob
no dimlight saving in the NT, time for a beer though … zulu time everywhere I say …