While walking down from morning coffee, I overheard a woman in the hall state that Japan did not use Daylight Savings Time (DST). To be honest, I thought everyone used DTS.
A quick Wikipedia search corrected me. From the posting, it looks like almost every country has at least tried DST,. Now days though more countries avoid it, then use it. Very interesting indeed.
Do I think we (i.e. U.S.) should use DST? If I had my preference, I'd like to use DST on weekdays so I have more sunlight during the evening hours when I'm at home with my family. On weekends, when I like to get up early and golf, I'd rather have the sun up as early as possible. There is nothing more enjoyable than watching your golf ball slice through the morning fog and rising sun. And earlier the better so I can get home and keep my wife and son happy.
Anyway, I'm glad I had coffee this morning and glad that I overheard the fact that Japan didn’t use DST. This fact may someday save me from missing an important book signing overseas.
Wednesday, October 17, 2007
Don't all countries use Daylight Savings Time?
Posted by Mac Noland at 7:15 AM
Subscribe to:
Post Comments (Atom)
5 comments:
If you ever had to write a class(es) to handle DST internationally, you'd be well aware how painful it is to manage DST, particularly when the US changes it (like in the last year) or random changes happen, some of them by only half an hour. My favorite is trying to account for missing hours and how to handle items posted into a time-recording system that occur in DST. You can use universal, but there are still considerations. The last module I wrote used a provider setup so that it could be strapped over custom XML (to integrate with legacy), a database, or even the MS timezone settings on an individual machine (very useful, as they update more often than a developer is likely to check). The best way I found was to use MS's values and cache them, or provide functionality to take those values and serialize them as XML as necessary so that changes can be triggered when desired.
Hey! Speaking of which, the New Horizons newsletter just came and contained this tidbit:
Time flies: DST ends Nov. 4 — are your systems ready? Here's what you need to keep in mind for next month.
From computerworld.com: Well, it's time to revisit some of that work—particularly if your company has international partners or customers. That's because several other countries—including Jordan, Egypt and New Zealand—adopted their own specific daylight-saving time updates since the time change took place in the U.S. last spring, meaning companies might want to update their patches again to ensure conformity when clocks spring forward next year. But first, companies have to deal with the return to standard time in most parts of the U.S. Clocks roll back an hour on Sunday, Nov. 4.
That's very interesting scooter. While I've never had to write any DST software, it has kept me up a few nights thinking about it.
Just recently we had to upgrade all our JVMs for the U.S. changes. I wonder if the friendly folks in Congress thought about that when they made the decision?
Of course, at least they made a decision, which maybe was the biggest accomplishment anyways... Not that I'm a cynical of Congress' output.. ;)
Not everyone in US uses DST, Time in the United States. I would be working at Burger King if I had to write software to account for DST. No thanks!
I'm no longer in IT but can imagine the gnashing of teeth when Congress adds 3 weeks to daylight savings. Frankly, I think the whole idea of jumping back and forth an hour is crazy. Let's march on Washington.
Post a Comment