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."

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:Simple

[GundamFan]

A certain retarded AC has no idea how an OS that starts with a W works.

You can set a Windows box to GMT...

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?)

Better article

[grimwell]

Verifying Timezone Settings in Linux [lsu.edu] lists common distros & needed patches and how-to verify settings. Waaay less wordy than the article linked in the summary.

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:Win vs Lin

[DrXym]

Linux apps are not somehow magically immune to breakage from DST patches. The simple fact is that if your computer solution comprises software from multiple vendor / maintainers then you should be extremely concerned about the DST change whether you're using Linux, Unix, OS X or Windows. Not only do you have to patch each system, but somehow verify to your own satisfaction that those patches actually work.

Especially if proper timestamping is a mission critical requirement, such as for real time systems, financial trading etc. In fact it's even worse for something like trading since you may be talking about literally hundreds, or thousands of distinct subsystems passing timestamps around between each other.

Solaris Test (was Re:A very simple *nix test)

[jmodule]

For Solaris you can still use zdump, just with a timezone entry instead of /etc/localtime:

zdump -v US/Eastern | grep 2007

From BigAdmin [sun.com]

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.

How to verify whether your system is up to date

[E-Lad]

Use the zdump command:

zdump -v [timezone] | grep 2007

If your systems's zoneinfo files are up to date, you'll get output showing DST changes on March 11 and November 4, eg:

$ zdump -v EST5EDT | grep 2007
EST5EDT Tue Mar 6 13:59:24 2007 UTC = Tue Mar 6 08:59:24 2007 EST isdst=0
EST5EDT Sun Mar 11 06:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 EST isdst=0
EST5EDT Sun Mar 11 07:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 EDT isdst=1
EST5EDT Sun Nov 4 05:59:59 2007 UTC = Sun Nov 4 01:59:59 2007 EDT isdst=1
EST5EDT Sun Nov 4 06:00:00 2007 UTC = Sun Nov 4 01:00:00 2007 EST isdst=0

That same command has worked for me on Solaris, Linux systems, and MacOS X.

Setting DST on older RedHat systems

[yuna49]

I have some servers running RH 7.3 for which there are no rpm-based updates that I could find (fedoralegacy having closed down). I followed the instructions in the article to update /usr/share/zoneinfo, but that alone doesn't do the trick. The file /etc/localtime on these systems is a static binary, not a link to /usr/share/zoneinfo/America/New_York or whatever's appropriate for your timezone. The fix is simply to delete /etc/localtime and create a symlink with the same name to the correct zone data in /usr/share/zoneinfo.

The short answer...

[pla]

Skipping all the crap and presuming you have an older distro that doesn't to automatic updates, I'll summarize the steps needed (Do this at your own risk, but it should work on any even remotely standard distro, even very old ones):

cd /tmp
wget --passive-ftp ftp://elsie.nci.nih.gov/pub/tzdata2007c.tar.gz [nih.gov]
tar -xzvf tzdata2007c.tar.gz
zic northamerica
ln -sf /usr/share/zoneinfo/EST5EDT /etc/localtime

If you live outside the civilized world, insert the appropriate time zone in place of EST5EDT. ;-)

And finally, verify it with:
zdump -v /etc/localtime | grep 2007
Which should say "Mar 11" and "Nov 4"

Re:How may we help you?

[Anonymous Coward]

"Microsoft - I see. Well, Stuart, the big hand is on the four and the little hand is......."

If it's 4:42, wouldn't the big hand be closer to the 8?

Re:Beware JVM Problems

[Tony Hoyle]

Proxy compatibility. MS Proxy server doesn't work with JVM 1.4 (and believe me there are still a lot of those around).

Not sure you'd see it in a home situation though.

Re:A problem with DST in general

[westlake]

Man has been telling time for centuries and it wasn't until the DST mess that we started having issues.

For most of human history, time meant local solar time, or time by the moon and stars. It isn't until the mid 18th C. that the "longitude problem" is solved by the invention of precision marine chronometers. It isn't until the mid 19th C. that the "standard time" demanded by the telegraph, the railroad, trade and industry, intrudes on the lives of ordinary people.

Re:Beware JVM Problems

[twivel]

It's not as simple as that. Not all 1.4 versions are patched for DST, only 1.4.2_11+. Further, there is a patch level for 1.3.1 that has the DST patches as well.

These are the java versions that natively include fixes for DST in 2007.
1.3.1_18+
1.4.2_11+
1.5.0_06+

So this means all 1.4.0 and 1.4.1 versions will not recognize DST unless you update them. Most vendors provided an update tool (tzupdater/jtzu) that can patch a variety of java versions. There is a table of available options for all vendors at: www.javasanity.org

Windows-only "Y2DST" bugs

[GodWasAnAlien]

If events are scheduled using UTC, then timezone and dst make no difference.

But if Outlook has "Y2DST" bugs, it stores or assumes that date/time is in local time, so events may be wrong if DST or the timezone of your server changes.

Note that these bugs if they exist could be reproduced otherwise by changing the timezone while programs are running. Events should happen at the same time, independent of timezone. (A real situation would be flying a live system/laptop to a new timezone).

But the bug in Windows is at a low level. Windows, for backward compatibility to DOS, assumes the hardware clock is local time. Any program that depends directly on the local time here, needs more than trivial algorithms to handle timezone and DST algorithms. These algorithms will fail, obviously if DST unexpectedly changes, and are probably in general not really expecting timezone to change. ( These algorithms could be compared with Y99-Y2K algorithms that tried to convert from a two digit year).
And obviously any programs that have such low level DST/Timezone handling code would fail if someone set the not often used RealTimeIsUniversal=1 in Windows.

In general no program should rely on local time, internally. Local time should only be used to convey information to the user. "You appointment is at XXX in your timezone", or "What time in your timezone would you like to schedule your meeting alarm?".

FreeBSD howto

[jefp]

I did my old FreeBSD systems yesterday. The procedure was as follows:

1) Fetch the new rules file. I got it from:
          http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/s rc/share/zoneinfo/northamerica?rev=1.31 [freebsd.org]

2) Save it as /usr/src/share/zoneinfo/northamerica

3) In /usr/src/share/zoneinfo do a 'make install' - this compiles the rules into /usr/share/zoneinfo/.

4) Run tzsetup - this copies the proper file from /usr/share/zoneinfo/ to /etc/localtime.

5) Do a 'locate localtime' to see if you have any copies of /etc/localtime in chroot trees, e.g. /etc/bind/. If so, copy the new one there too.

If you have multiple identical systems you can do this on one and then copy the new /etc/localtime to the rest.

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.

Re:Win vs Lin

[Anonymous Coward]

Fact is that Linux libraries have supported variable DST rules for about 15 years now, while Windows has introduced it only with this DST patch (available for XP and higher only).
This means that Linux systems only need a rules update that silently slips into the already existing system that applications were always supposed to use, while in Windows there is functionality change and you could run into problems with applications that do not expect that different rules are present for different years.

So in Windows, you patch your system and have to re-test everything, while in Linux you just load a TZ rule and everything keeps working.

Re:Solaris Test (was Re:A very simple *nix test)

[hawg2k]

In Linux:
zdump -v /etc/localtime | grep 2007

Re:Windows-only "Y2DST" bugs

[onemorechip]

UTC doesn't solve it.

I have a recurring meeting. It is at 11 AM Pacific Time every Tuesday, all year round.

Do I just set it up for 1900 UTC then? No, because when DST takes over, it will be off by one hour. Instead, I set it to 11 AM local time. MS Exchange performs the adjustment and schedules this meeting (and the conference room) for 1900 UTC for the winter months, shifting it to 1800 UTC when the software thinks DST takes effect. It doesn't calculate the times on the fly; it sets up the recurrences when the original scheduling is done. If the meeting was scheduled before Exchange is updated with the new DST, then, for each occurrence between March 11 and April 1, the meeting appears in my Outlook calendar *one hour later than it should*. This is because the updated software knows that 1900 UTC (the scheduled time) is actually noon local time.

What's more, the conference room is now available between 11 AM and noon on Tuesdays, for someone else to schedule a meeting. When IT corrects my meeting schedule for the time change (which they will, as they have advised everyone in the company not to try to do this manually), there's gonna be trouble...

Re:A very simple *nix test

[generic]

zdump -v US/Eastern |grep 2007

FYI, Red Hat's Patch is Incorrect!

[h4ck7h3p14n37]

Just a head's up to anyone running Red Hat that their DST patch is incorrect. It's switching to Daylight Saving Time two hours earlier than it's supposed to.

CST6DST Sun Mar 11 05:59:59 2007 UTC = Sat Mar 10 23:59:59 2007 CST
isdst=0 gmtoff=-21600
CST6DST Sun Mar 11 06:00:00 2007 UTC = Sun Mar 11 01:00:00 2007 DST
isdst=1 gmtoff=-18000
CST6DST Sun Nov 4 04:59:59 2007 UTC = Sat Nov 3 23:59:59 2007 DST
isdst=1 gmtoff=-18000
CST6DST Sun Nov 4 05:00:00 2007 UTC = Sat Nov 3 23:00:00 2007 CST
isdst=0 gmtoff=-21600

Clock's are supposed to roll forward an hour at 1:59 A.M. not midnight.

We're having some fun with these patches. We've got about 400 machines to update (with three people) and are running about two dozen different releases of FreeBSD, OpenBSD, Red Hat Linux, Debian Linux, SCO, Solaris and Windows operating systems. And those are just the production servers; I can't wait until we do desktops.

Re:Windows-only "Y2DST" bugs

[Ungrounded Lightning]

If events are scheduled using UTC, then timezone and dst make no difference.

Given that events (such as periodic meetings) are normally scheduled in local time, that's bogus.

In fact, having the calendaring tool store them in UTC breaks things even more. It means that the tool will convert them to UTC to store them and alarm them, then back to local time to display them. So when DST starts (even if at the EXPECTED time) a periodic meeting moves by an hour.

DST is an unmitigated disaster for programmers who write scheduling software (as I once did for a client). Changing it compounds the problem.