Linux Systems and the New DST

An anonymous reader writes "The recent changes in the Daylight Saving Time will affect virtually all computer systems in the US one week from now. Microsoft has been busy preparing Windows users for 'Y2DST,' and all the major Linux distributions have also issued patches. How can you be sure your Linux systems are ready, and what can you do to get them ready if they're not? This how-to article at Linux-Watch answers both questions in simple language and with easy-to-follow instructions."

Comments

A very simple *nix test

[Iphtashu Fitz]

$ date --date="Mar 25 15:00:00 UTC 2006"
$ date --date="Mar 25 15:00:00 UTC 2007"

If the output of both shows the same time (eg. 10:00 EST) then you've got a problem. If they show different times (eg. 10:00 EST and 11:00 EDT) then your system is ok.

Win vs Lin

[stry_cat]

Funny how with Linux there isn't any danger of your entire system breaking. I know we spent every day since the Windows patches were relased, testing and make sure the patches don't break anything. So far our Exchange server had to be restored from backup once already b/c all the calendar entries got screwed up.

Re:NTP?

[overshoot]

How does this work with NTP? Will the system just stay up-to-date from another system that understands the new rules, or does NTP all work on UTC so that it's not aware of this, or something?

NTP will keep you system clock (as Heaven intends) coordinated with UTC.

However, if you're using an old zoneinfo file for local time, the interpretation of that UTC time is something else again, and NTP won't help you at all.

(Well, assuming you don't live in Arizona or Hawaii. Indiana's timing sucks, doesn't it?)

Beware JVM Problems

[tritonman]

If you have systems running JVM 1.3 that interact with systems using 1.4 or above, beware, there are issues in how they implemented the fix in 1.3. In Java 1.3, the DST change is applied to ALL years, including prior to 2007, so if you have a remote object on 1.3 give a date to an application running in 1.4 (as a binary object, not just text) then it will cause problems, it will set it to 1 hour off, if you don't use timestamps, the default will be midnight, so one hour off will be the previous day. This has caused a bunch of problems where I work.

Re:NTP?

[E-Lad]

I've seen and heard a lot of people say "I run NTP, I'm immune to this". Sadly, they're just showing that they don't know how NTP works, even on a basic level.

NTP as a protocol tracks the number of seconds elapsed since 1 January, 1900 UTC. It has absolutely zero knowledge of timezones or what they mean. Your NTP daemon of choise just sits there keeping your system clock reasonably accurate with UTC time and it's the relevant libc C time functions that read that UTC time, then read in the set zoneinfo data, and combine the two to give you and your apps local time.

Multiple timezone meetings

[farnz]

To give you an example of a meeting that spans several timezones; we needed to hold a teleconference with people in the UK, Australia and the US. Within the US, a company with offices in New York and San Francisco faces the same issue; you have people in different timezones, who need to agree on a time.

It's not possible to get a perfect solution to the problem. The best design I've seen stores times in UTC, together with a description of the entry timezone and the offset. Each user has a current local timezone (and it's assumed that users who travel will track these problems for themselves). When a change to DST comes along, the administrator can do some or all of the following:

• Adjust meetings such that meetings entered in the timezone that's changing are at the same local time (but a different UTC time).
• Adjust meetings such that meetings entered in the timezone that's changing are at the same UTC time (but a different local time).
• Alert everyone who's involved with a meeting where one or more participants are in a timezone that's changing to check that the time is still valid.

The system also allows users to override the entry timezone on a per-entry basis. This means that I can enter a meeting in the UK marked as 9am Atlanta time, and be confident that it'll not only appear properly, but that if Atlanta's timezone changes on me, it'll be updated properly.