By BoLOBOOLNE payday loans

Global XML config for time change rules

I’m sure by now most of you have heard that last summer congress legislated a new start to Daylight Savings Time this year.  Instead of the first Sunday in April it’s going to start on the second Sunday in March from now on — March 11 instead of April 1 this year.  Overall I think this is a good change — I’d prefer daylight savings time year ’round, except for that part where kids get run over going to school in the dark.

But it is of course playing havoc with computer systems everywhere which have the DST rules built into hardware and software everywhere.  (As somebody[ref?] pointed out don’t trust your meeting reminders for those couple of weeks!)  A DBA I work with described the problem as "worse than Y2K" which I can totally believe since this change comes with just 7 months warning, whereas I started writing code to be Y2K aware in the mid-80’s and others started well before that.

I don’t write to this blog often enough for it to be worth anybody’s time for me to re-report news.  There’s plenty of bloggers who do that already — you don’t need me to filter what’s interesting for you.  So I always try to add some personal value in whatever I’m talking about.  The question I’ve been wrestling with here is: How can we avoid this kind of problem in the future?

"Always use network time" is one obvious answer, and for some things that’s all you need.  I don’t trust clocks that are set internally and can drift.  Cell phones, computer clocks (on well-run computers), the clock on my desk phone — all these are set from a reliable central source and I believe them.  But this answer isn’t good enough for any software that has to plan things in advance. Any kind of scheduling or calendaring software needs to know when time changes are going to occur in advance.  So just having the central network clock tell you that the time has changed unexpectedly doesn’t solve your problems.

As I said, many systems have the rules for time changes hard-coded.  To avoid this kind of problem in the future, these rules need to be configurable.  This is basic Software Engineering — don’t hard code things that change.    I don’t know how often this kind of change happens in the world, but I’m guessing it’s not infrequent especially if you take a global view of things.  I expect some countries change their timezone rules about as often as they change dictators.  (If I was a ruthless dictator I’d probably set my country 15 minutes off from my neighbors just to mess with everybody!)

Then the right answer is to move time change and timezone configuration to a central place on the net.  Any place will do, so long as it’s reliable.  It should be highly available and distributed and secure and of course have some well-structured XML format.  None of this is hard — we know how to do all these things.  The consuming systems would only need to ping this service every week or month to see if any thing had changed.  The hardest part of doing this would be avoiding getting stuck in standards body bureaucracy and subsequent scope creep.  Actually doing it would not be that hard.

Comments are closed.