developer.* Blogs - Software Design - Comments

12 days in jail for a nonexistent bomb threat owing to DST bugs?

Edward G Nilges — Fri, 20 Apr 2007 22:40:38 -0700

What's really nuts is giving the kid a 12 day jail sentence EVEN IF he had really phoned in a bomb threat. In former times, kids who got in trouble as first time offenders were let off with a warning, but today, grownups, who haven't grown up, are frightened of their own kids.

Terrorism? Give me a break. All this "zero tolerance" failed to prevent the killings at Virginia Tech because it makes human time bombs into things undeserving of help in advance of going off.

Kid probably has a lawsuit for wrongful arrest but unless he has a rich Daddy as did those kids at Duke wrongfully accused, it'll go nowhere.

I am glad to be out of America.

The ultimate DST bug?

Daniel Read — Thu, 19 Apr 2007 16:45:55 -0700

This may be the ultimate Daylight Savings Time "bug": Kid wrongly imprisoned for bomb threat - error due to Daylight Savings Time.

Dan

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.

I don't think we have that

Guest — Tue, 13 Mar 2007 12:12:22 -0700

I don't think we have that in Europe. I didn't know you could do so many things in a voice mail, I thought the point was to simply leave a message.
So, here, you only have to listen to the silly "you have called to number 123455..." (as if you didn't know which number you were calling to, or if, otherwise, you were going to realise that one of the numbers was wrong) "...please leave your message after the beep". And that's all. No callback stuff (it's always easier and faster to just mention your phone number in the message) and no beepers options (who has a beeper, anyway?) (I think pager and beeper are the same thing)

DST is a problem even in Hong Kong...

Edward G Nilges — Sun, 11 Mar 2007 01:12:03 -0800

If your workday has to coincide with financial markets.

Don't trust the date time control in Windows XP if you are working in Europe or Asia, and you want to call your Mom, and you don't want to wake her up. Go to an online site in the USA that is DST change aware.

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.

DST Embedded Everywhere

Daniel Read — Fri, 09 Mar 2007 06:48:04 -0800

I came across this bulletin today about the DST bug that is going to appear in a few days in a Sirius satellite radio model called the Stiletto. This underlines for me how pervasive this problem is, and makes me wonder whether lawmakers really thought this through before passing this law (I suppose that's a stupid question...of course they didn't!).

How long will it take the theorized energy savings from this move to exceed the losses by businesses in implementing this change? It's easy to throw stones at companies that are having trouble implementing and supporting patches, but the sure didn't ask for this.

This, in an ironic way, points back to one of the original points of my DST post (see top of thread), which I wrote long before I had heard any talk about the 2007 DST change that's causing so much uproar as I write this comment: DST bugs seem to bite software shops and enterprises twice a year, year after year. This year's DST issue is just an extreme sort. Next year we'll go back to normal, everyday DST bugs, which (in parts of the world where DST applies) will probably be with us forever.

An excerpt from the Stiletto bulletin:

At 2 a.m. Sunday, March 11, 2007, Daylight Saving Time (DST) starts three weeks earlier than usual in a federally mandated effort to save energy. At this time, the Stiletto 10 and 100 will not be able to automatically compensate for this recent change. If you live in a time zone which observes DST the time on your Stiletto will be one hour behind until April 1st, the previously observed beginning of DST. On April 1st, 2007, the time setting on the unit will be corrected.

In general, your device will continue to operate normally during the brief period the time setting is incorrect. There will be no impact to your ability to receive programming or use the LOVE function. However, if you intend to use timer recordings during this period, you will need to take steps to compensate for this offset.

I wish I had me a LOVE function!

Dan

An Aparent Mess with Microsoft DST Patches

Daniel Read — Thu, 08 Mar 2007 08:14:18 -0800

The saga continues with the current Windows DST switchover: Mary Jo Foley of the "All About Microsoft" blog relates the tale of user woes with the DST patches.

Dan