Daylight Saving Shift
in [Java Programming]
|
From: Martin Gregorie on 1 Nov 2009 15:05 On Sun, 01 Nov 2009 03:04:39 -0800, Roedy Green wrote: > Daylight saving shift back happened 2AM this 2009-11-01. > Not anywhere I've lived, apart from a year in NYC. OTOH, I've only resided in countries that use DST but I've never seen the point. I'd rather keep the clocks fixed and, if anything should be changed, change business and school, etc. hours. The most people-friendly arrangement I've met was the one India used in the late 70s: since winter days are shorter than summer days, business hours were adjusted accordingly: IIRC winter opening times were about two hours less than summer hours. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Arne Vajhøj on 1 Nov 2009 15:10 Arved Sandstrom wrote: > Joshua Cranmer wrote: >> 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. > > 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. Yes. But it is a problem. I don't know what Outlook does, but it does not always work well for a reoccurring meeting scheduled over DST changes. Arne
From: Arne Vajhøj on 1 Nov 2009 20:59 Lew wrote: > Arved Sandstrom wrote: >> Just as for the rules for magnetic declination, I don't even try to >> remember any of that. It's easy enough to work out from first >> principles and local knowledge. For example, if you know that DST is >> intended to give you more hours of light in the evening, that >> immediately tells you in what direction the clock must go. > > The irony is that Daylight Savings does not give you more hours of light > in the evening. It just makes people go to (and thus leave) work an > hour earlier. The evening itself still has the same number of hours of > light. Not if the evening starts when you are home from work. Arne
From: Roedy Green on 1 Nov 2009 21:15 On Sun, 01 Nov 2009 13:26:42 GMT, Arved Sandstrom <dcest61(a)hotmail.com> wrote, quoted or indirectly quoted someone who said : >2009 software finally could have solved these date/time problems. The catch is every program that deals with time needs to be aware of the shifts. Java handles most of the problem in class libraries, but you still have the problem of data input, given that 2009-11-01 2:01 is not a unique identifier of a time instant. Most programs just ignore the problem or use standard time. DST is not going away. Perhaps we could use it all year. That would get rid of the shifts which are the major bugbear. I see no advantage in losing an hour of evening daylight in November. Maybe we will see DST creep till it totally takes over. The other possibility, at least for Internet communication, email and international meetups is to use UTC. -- Roedy Green Canadian Mind Products http://mindprod.com An example (complete and annotated) is worth 1000 lines of BNF.
From: Arne Vajhøj on 1 Nov 2009 21:23
Roedy Green wrote: > On Sun, 01 Nov 2009 13:26:42 GMT, Arved Sandstrom > <dcest61(a)hotmail.com> wrote, quoted or indirectly quoted someone who > said : >> 2009 software finally could have solved these date/time problems. > > The catch is every program that deals with time needs to be aware of > the shifts. Java handles most of the problem in class libraries, but > you still have the problem of data input, given that 2009-11-01 2:01 > is not a unique identifier of a time instant. There should be an isAmbiguous method somewhere in a class. > Most programs just > ignore the problem or use standard time. I don't think so. Such a program would be rather tricky to write. > DST is not going away. Perhaps we could use it all year. That would > get rid of the shifts which are the major bugbear. > > I see no advantage in losing an hour of evening daylight in November. > > Maybe we will see DST creep till it totally takes over. The politicians make that decision. We just need to write the software to match those decisions. Note that even if DST changes were completely removed, then we would still need to support it due to historical data. Arne |