Argentina's DST: software vendors' reactions

Greetings!

As almost everyone must know by now, Argentinian government decided to implement Daylight Saving Time for this summer, starting on December 30th and ending on March 16th.

This decision was taken on December 27th, leaving only three days for everybody to take the appropriate action. Three days on December. Three days really close to the New Year. Three days on which most people are thinking on holidays and partying. This lack of foresight is the trigger for this article’s debate.

Many, many IT companies and communities had to do something to keep up with this update. I, myself, had to deal with some of them, and these are my thoughts on the subject.

Debian GNU/Linux and Ubuntu Linux

The update was absolutely clean. On Ubuntu, in the computer at my work, I configured Synaptic to download and install updates as they become available, and so it happened. The first work day after the switch, the right time set, with zero interaction required.

At home, on Debian, the configuration is such that it downloads packages and I decide whether to install them or not. Anyways, since the update was ready on December 29th, I installed it before the switch, and the same thing happened. Totally flawless.

Palm

Palm hasn’t released yet an update for Argentina’s DST (or at least, I haven’t been able to find it). Their newest update seems to be this, which (as of today) only applies for US modifications on their DST.

However, they do have a very neat way of defining Daylight Saving Times on any given city, through the World Clock application. A brief tutorial can be found here.

So, Palm’s response can be considered good after all. At least, better than others. Go on reading.

Microsoft Windows

Microsoft’s response was fast, really fast. But not good at all. I would’ve expected them to give us a small, nice patch through online update services for desktops and servers, instead of a Registry file and a tutorial. The same applies to Outlook.

Another Microsoft software I’ve had to deal with is Windows CE. The solution, again, seems to be a Registry file, although I didn’t dare to try it.

What I feel is: Microsoft had the chance to use their update services appropriately for one time and they didn’t. I’m not aware if such a service exists for Windows Mobile, but again, there were no magic solutions from the leading company in software. Not good.

Sun Microsystems

Sun’s Java Virtual Machine has its own locale definitions, and so, its own Time Zones and DST rules. They get this information from the Olson database, as stated here.

They’ve only recently updated this package, so at least for response time, I’d say I’m not satisfied. As for the effectiveness of it, it works on Linux without problems. Windows has an issue, but I think Sun’s not to be blamed on this one.

Conclusions

I think Debian’s approach is perfect. Zero interaction required, totally transparent, and in time. It felt like magic.

PalmOS’s is not so bad itself, as it needed interaction but the guidelines where very clear and easy to follow.

Sun’s patch works. I believe it wasn’t delivered on time, but it accomplishes its goal.

About Microsoft, I cannot say the same. A Registry file is not something a common user can use or understand. Microsoft is well known for their user-friendly GUIs. And since they have tools like Windows Update, their solution looks quite unacceptable for me. This gets worse when you remember you paid for Windows.

Even worse, that Registry file breaks Sun Java’s Buenos Aires Time Zone, even with Sun’s latest JRE and Time Zone patch. It renders the locale useless, since it doesn’t update the mapping used by the JRE to recognize Buenos Aires, so the JRE uses the hardcoded fallback, GMT. The same does not happen on JRE’s running on Linux. Again, Linux’s update was perfect.

References

Aknowledgements

to Román García and Maxi Vazquez, for helping on examining the JRE’s insights and finding the issue with Microsoft’s fix.