developer.* Blogs - Daylight Savings Time Software Problems: Who Is At Fault? - Comments

Lesson Learned

phacdelm — Tue, 20 Mar 2007 10:43:04 -0700

The author of the article asked for lessons learned from the DST change this year.

We learned that we had inadvertently saved ourselves a whole lot of work by storing dates and times in LOCAL time in our DB.

That way, we could apply the appropriate patches, fire up the applications again and be up and running without much strain.

I had long bemoaned the fact that we didn't use UTC to store dates. If we had, all those timestamps would have had to be adjusted with the change over. But... non-DST timezones would then receive incorrect data.

I've got no conclusions yet on which I'll chose for my next project (local or UTC), but my experiences on DST 2006 will be taken into account.

That's a terrible idea.

Guest — Mon, 19 Mar 2007 06:36:18 -0700

That's a terrible idea. You think it's complicated now.

You're doubling or tripling the number of effective time changes. "Oh, the sun rose today at 7:01 instead of 6:59 so instead of having an hour before work I now have 90 minutes?" And for people a few towns west it's now rising at 6:59 instead of 6:57 so they still start work at 9:30 (half hour quantization) and I start at 10?

DST, Unicode, Timezones, DNS, l10n, I18n ...

mikx — Fri, 16 Mar 2007 07:00:07 -0700

It seems part of the problem is that most software comes from - or at least has it's origin - in the USA or UK.

In a software world treating everything beyond A-Z,a-z,0-9 as a mysterious black art it is no wonder "modern software" fails an trivial tasks like DST.

It would be wonderful having a senior manager at Microsoft with special characters in his surname and a wife in Nepal being in a timezone +5:45 UTC. His mother might be a Japanese women speaking and reading only Japanese, his uncle could be colorblind, his sister being handicapped and not able to use a mouse, his brother might run a small company struggling to create some piece of a/v equipment for DJs and being threatened by obscure patents....

Well... just an idea...

Clarification

Guest — Thu, 15 Mar 2007 00:40:20 -0700

The clocks would not be changed. They'd always be on standard time, as usual. Time zones would continue to exist, and time would be quantized. Business hours, however, would be malleable, based on the time when the sun rises.

The point of DST was to increase the amount of useful daylight. Going with a sun-based business day, where the start of the official business day is relative to dawn, would optimize for this goal.

For example, if the sun rises at 6am, then you can say the official business day starts at 9am. If it rises at 5am, then it starts at 8am. If it rises at 7:00, then business starts at 10:00. Businesses could individually decide when the degree of quantization they wish to support. Perhaps they'd use half-hours.

It would create confusion for businesses, but, only at the start and end of the day.

Solar time isn't the answer

Ron Porter — Wed, 14 Mar 2007 07:32:51 -0700

At least I don't think it is. Anybody who cares to listen knows that I'm quite willing to rant against DST at the drop of a hat. Standard Time, on the other hand, is a boon to mankind.

My experiences with working on the railroad may have left me biased, but I can't imagine trying to conduct even basic family business where everybody sets their watch by solar noon. Every few miles you end up a few minutes further out of sync. No, I think standard time, with most time zones incrementing by a full hour, makes the best of an awkward world.

And I'll stop now, before I start ranting against DST.

Oh if it were so simple

Guest — Wed, 14 Mar 2007 03:47:49 -0700

My computers get their time from the server, but the fact that MS didn't issue a hotfix for Win2K assured that those machines would not get DST correct. A few utilities fixed this, but they were not part of the automatic updates.

The fix was not that difficult, and was detailed in an MS KB article.

The real problem is DST. We should just get rid of it, and learn to conduct our daily business by the sun. The day should start after dawn. It's entirely feasible. We have computers and devices that can calculate when the sun rises, and can issue an alarm at that time. The start-of-day can be offset from dawn. You get 2 hours of "morning" time to yourself. Then you get 8 hours or so of work, followed by "evening".

If the clock "breaks", we can rely on the sun and our circadian rhythms.

Whee

Ed — Fri, 09 Mar 2007 13:17:25 -0800

Sirius should be spanked, long and hard. The DST change law was passed a year before the devices in question hit the market. For that matter, who the hell designs a piece of consumer electronics with a clock whose clock can't be set by the user? And posting a technical bulletin two days before the event, well that's pathetic.

I blame the software manufacturers. We've had almost two years to implement this change. Two years people. Whether your solution is flexible or not, you should have been able to compensate for the change in the last two years...

For anyone running Microsoft software that will be affected by a problem with a DST change, here's your solution: Open the Windows clock, go to the timezone tab. Uncheck the box marked "Automatically adjust clock for Daylight Savings Time." Now, push out a group policy to force network machines to synch their time with your local time server. At 2am or whenever the hell the pinheads in DC have decided the time changes, you get up, change your server's time, have a beer and go back to sleep. That'll be $4,000 thankyouverymuch.

--Ed

Oh yeah, Hi Dan!

daylight savings time

Brad Bellomo — Fri, 09 Mar 2007 12:56:57 -0800

This is not a "massively complex undertaking" - software itself is more complicated than anything else mankind designs - this is a trivial task of changing the time, and it is only 7 years since Y2K.

Whose to blame? People who keep buying mediocre and bad software. Software salesman continue to make a mint, resources to test, redesign and fix software get cut, and vendors without good salesman who put resources into quality products are ignored. When a badly made product breaks, everyone gets mad for a while, and then keep buying the same stuff from the same vendor. If consumers and corporate buyers made quality a higher priority, you can bet software companies would.

I'm the Argumentative Colleague...

Bruce — Fri, 09 Mar 2007 12:30:16 -0800

Basically, my position is that if your product or application is a timekeeper; if that is part of your functionality; then any design that treats DST as a given, or hard-codes it in any way, is poor design.

To expect DST to stay set in stone for the convenience of technology companies, when the measure is a conservation measure less than 40 years old... that's just a lack of proper planning.

Congress didn't enact this "recent" change without an adequate implementation window, either. They were certainly aware of the capacity for disruption and the need for time to adapt. If your underlying design acknowledged the possibility that the implementation dates of DST were subject to change, there was certainly ample time. What I am saying is that any architecture that treated DST as not being subject to change in the first place is at fault. Further, given the generous implementation window, any IT services professional struggling to patch *today* is arguably to blame also.

I certainly agree that there can be a lot of complexity in working out the details of these changes, but to point the finger at congress for the costs incurred is akin to blaming Astronomers for the cost to reprint textbooks that still list Pluto as a planet.

Bottom line: If being "smart" about DST is functionality you are paid to deliver, you have an obligation to deliver it. Any design that for all practical purposes hard-coded DST, was (especially in the wake of Y2K) poorly designed, and quite possibly negligent.

I think there might be fertile ground for a class action lawsuit to that effect.

Daylight Savings Time Software Problems: Who Is At Fault?

Daniel Read — Fri, 09 Mar 2007 11:40:24 -0800

What do you think? Are there fundamental lessons here that software designers and companies should be heeding? Are there some products or manufacturers that got this *right*, who have not experienced difficulties with the great 2007 DST transition? If so, what can we learn from their example?