Comments on: Fall Back: Europe Moves to Winter Time, U.S. Changes Clocks Next Weekend http://www.basexblog.com/2009/10/24/daylight-savings-time-2009/ Tue, 09 Mar 2010 11:25:00 -0500 http://wordpress.org/?v=2.9.2 hourly 1 By: 10 Monday Reads | The Big Picture http://www.basexblog.com/2009/10/24/daylight-savings-time-2009/comment-page-1/#comment-2599 10 Monday Reads | The Big Picture Mon, 26 Oct 2009 20:01:17 +0000 http://www.basexblog.com/?p=1086#comment-2599 [...] Fall Back: Europe Moves to Winter Time, U.S. Changes Clocks Next Weekend [...] [...] Fall Back: Europe Moves to Winter Time, U.S. Changes Clocks Next Weekend [...]

]]> By: Mike O'Dell http://www.basexblog.com/2009/10/24/daylight-savings-time-2009/comment-page-1/#comment-2597 Mike O'Dell Mon, 26 Oct 2009 16:23:13 +0000 http://www.basexblog.com/?p=1086#comment-2597 There is only one "time zone" which is correct all the time and that's UTC. My day job is in a company with offices on both coasts of the US, two sites in China and two in India. Organizing a meeting is agonizing because everyone uses local time and it's a continuing battle to get anything right. I have tried many times to convince people that meeting planning should be done in UTC so at least that source of confusion is eliminated. But no. Everyone tries to explain how that would be complicated. Somehow knowing just their own UTC offset is seen as more complex than knowing the full cross-product of relative offsets. On their own heads be it. There is only one “time zone” which is correct all the time and that’s UTC.
My day job is in a company with offices on both coasts of the US, two sites in China and two in India. Organizing a meeting is agonizing because everyone uses local time and it’s a continuing battle to get anything right. I have tried many times to convince people that meeting planning should be done in UTC
so at least that source of confusion is eliminated. But no. Everyone tries to
explain how that would be complicated. Somehow knowing just their
own UTC offset is seen as more complex than knowing the full cross-product of
relative offsets. On their own heads be it.

]]> By: Bob Frankston http://www.basexblog.com/2009/10/24/daylight-savings-time-2009/comment-page-1/#comment-2590 Bob Frankston Mon, 26 Oct 2009 03:11:34 +0000 http://www.basexblog.com/?p=1086#comment-2590 A follow-up note – my wonderful Panasonic DMC-TS1 is able to keep local time as a delta off the base time but, alas, it doesn’t know about these changes. How do devices deal with these issues as they get smarter but not wiser? A follow-up note – my wonderful Panasonic DMC-TS1 is able to keep local time as a delta off the base time but, alas, it doesn’t know about these changes. How do devices deal with these issues as they get smarter but not wiser?

]]> By: Bob Frankston http://www.basexblog.com/2009/10/24/daylight-savings-time-2009/comment-page-1/#comment-2585 Bob Frankston Sun, 25 Oct 2009 19:50:26 +0000 http://www.basexblog.com/?p=1086#comment-2585 Turkey did the switch at 4AM this morning (Sunday Oct 25th). This had an interesting side-effect as I was flying from Shanghai to Istanbul during the transition. I wondered why the plane was reporting time an hour later than I had set my watch to but it also showed us landing an hour late. Turns out, of course, that the plane was correct about the takeoff time but wrong about the landing time. I can understand getting this wrong – it’s the kind of thing the program (or programmer) just doesn’t deal with (same as a good UI on the per-seat user interface for the screen). Another related problem with calendar events is that the syntax doesn’t have good ways to deal with rich time representation. How can I say the meeting is 2PM in Istanbul and doesn’t change when the daylight changes? And is an all day meeting really all day or should the end points change? More fun is when you have multiple operating systems and reboot and each tries to correct for DST. I pushed for putting the time zone in the nonvolatile RAM rather than in the OS but I didn’t convince people. It’s a reminder of why Y2K wasn’t a big deal as these kind of issues are endemic but not a big deal because we take them in stride and don’t pile them on top of each other. It’s also a reminder why the leap second is so incredibly stupid – time is approximate to the nearest hour and we care about nanosecond precision? And China has just one time zone – I’d like to understand more about how that works in practice. Well enough for now – my body is zoning out … Turkey did the switch at 4AM this morning (Sunday Oct 25th). This had an interesting side-effect as I was flying from Shanghai to Istanbul during the transition. I wondered why the plane was reporting time an hour later than I had set my watch to but it also showed us landing an hour late. Turns out, of course, that the plane was correct about the takeoff time but wrong about the landing time.

I can understand getting this wrong – it’s the kind of thing the program (or programmer) just doesn’t deal with (same as a good UI on the per-seat user interface for the screen). Another related problem with calendar events is that the syntax doesn’t have good ways to deal with rich time representation. How can I say the meeting is 2PM in Istanbul and doesn’t change when the daylight changes? And is an all day meeting really all day or should the end points change?

More fun is when you have multiple operating systems and reboot and each tries to correct for DST. I pushed for putting the time zone in the nonvolatile RAM rather than in the OS but I didn’t convince people.

It’s a reminder of why Y2K wasn’t a big deal as these kind of issues are endemic but not a big deal because we take them in stride and don’t pile them on top of each other.

It’s also a reminder why the leap second is so incredibly stupid – time is approximate to the nearest hour and we care about nanosecond precision? And China has just one time zone – I’d like to understand more about how that works in practice.

Well enough for now – my body is zoning out …

]]>