Daylight Saving Shift
in [Java Programming]
|
From: Roedy Green on 1 Nov 2009 06:04 Daylight saving shift back happened 2AM this 2009-11-01. For tips on handling DST in Java and in the OS, see http://mindprod.com/jgloss/dst.html Check out the links. -- Roedy Green Canadian Mind Products http://mindprod.com An example (complete and annotated) is worth 1000 lines of BNF.
From: Joshua Cranmer on 1 Nov 2009 07:30 On 11/01/2009 06:04 AM, Roedy Green wrote: > Daylight saving shift back happened 2AM this 2009-11-01. Only if you live in Canada or the US. In Australia, the shift forward happened about 28 days ago, and it happened in New Zealand the week before (I think). In Europe, the shift back happened last week. In myriads of other countries, the change happens not at all or at other times. In short: March, April, September, and October are hell for scheduling meetings as you try to decide who is on DST and who is not. Also, while I do appreciate your attempts to remind us of important yearly chronological headaches, keep in mind that approximately 95% of the world does not live in the US or Canada and thus does not follow the same DST rules. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
From: Arved Sandstrom on 1 Nov 2009 08:26 Joshua Cranmer wrote: > On 11/01/2009 06:04 AM, Roedy Green wrote: >> Daylight saving shift back happened 2AM this 2009-11-01. > > Only if you live in Canada or the US. > > In Australia, the shift forward happened about 28 days ago, and it > happened in New Zealand the week before (I think). > In Europe, the shift back happened last week. > In myriads of other countries, the change happens not at all or at other > times. > > In short: March, April, September, and October are hell for scheduling > meetings as you try to decide who is on DST and who is not. [ SNIP ] Makes you wonder why one even needs to (I acknowledge that these days a person does still need to, more often than not.) After all, when a meeting is set up for a given date it's understood to be at a certain time for a certain participant in a certain location. When that participant says 2 PM he means 2 PM regardless, and you'd think that in 2009 software finally could have solved these date/time problems. After all, it's not like the problem is exactly an extremely difficult one, although it seems to have taken on that mantle. I think it's more a commentary on the state of programming rather than on the intrinsic difficulty of the problem that we still have these issues. AHS
From: Joshua Cranmer on 1 Nov 2009 09:09 On 11/01/2009 08:26 AM, Arved Sandstrom wrote: > When that > participant says 2 PM he means 2 PM regardless, and you'd think that in > 2009 software finally could have solved these date/time problems. Say a meeting (via telephone, not face-to-face) takes place at 9 AM Pacific, 5 PM British time on a recurring basis. Is the time coordinated to UTC (therefore doesn't change during DST, you have to account for it manually), coordinated to the US Pacific time, or is it coordinated to the British time? Throw in another dozen localities and suddenly publishing the local times for every participant is a nightmare. Plus you have the messy business of trying to remember twice a year whether or not you have to change your clocks back an hour or forward an hour. Spring back, fall forward or fall back, spring forward? They both sound correct to me... -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
From: Patricia Shanahan on 1 Nov 2009 09:25
Joshua Cranmer wrote: > On 11/01/2009 08:26 AM, Arved Sandstrom wrote: >> When that >> participant says 2 PM he means 2 PM regardless, and you'd think that in >> 2009 software finally could have solved these date/time problems. > > Say a meeting (via telephone, not face-to-face) takes place at 9 AM > Pacific, 5 PM British time on a recurring basis. Is the time coordinated > to UTC (therefore doesn't change during DST, you have to account for it > manually), coordinated to the US Pacific time, or is it coordinated to > the British time? Throw in another dozen localities and suddenly > publishing the local times for every participant is a nightmare. and in some cases the exceptional local time may not be acceptable. Most participants in a multi-site meeting also have local meetings, scheduled according to their local time. Just finding a time for a multi-site meeting that does not conflict with any must-attend meeting for any necessary participant can be a challenge. A one hour shift may create a conflict. Patricia |