Daylight Savings and UNIX?

Anonymous asks: "My company recently asked me to write them a report on how UNIX properly handles the switch to Daylight Savings Time, and back again. When our systems administrators received the report, I was somewhat surprised. Many of them weren't aware that 'cron' would run the affected jobs twice in the fall, and not at all in the spring. Apparently, the man pages on some operating systems, like Solaris, aren't forthcoming with details. Others groups, like database administrators, are completely unaware of the differences between epoch time and wall clock time. Are even technical users ignorant on how UNIX handles time, time zones, and time conversion?"

Comments

In FreeBSD...

[cperciva]

In FreeBSD, the default times for daily/weekly/monthly cron jobs are chosen so that they don't fall within the daylight savings time mess.

Dual boot?

[Gerry Gleason]

Of course, this is the right solution, and it is probably universal for UNIX vendors (Sun, HP, IBM, ...), but when your running on PC hardware there are extra considerations.

Linux gives you a choice about how to keep the hardware clock (Local or UTC), and the system clock is UTC with an offset setting for local time. If you're single boot with Linux, a UTC hardware clock is probably best, but if you ever want to boot into Windows, your going to have to adjust somehow.

Having the hardware clock in local time creates a problem when the time change happens, but you don't see it until you reboot. Someone incorrectly said you need to update from the hardware clock, but it is just the opposite, you have to update the hardware clock from the system clock after the time change. Since the system knows both when the change happens and whether the hardware clock is in local or UTC, it could take care of this little detail. It would be a nice touch for the distribution makers to handle this is some way. This is one of those things that doesn't really live in a single program/module but relates to interactions, so the distribution maker probably should own it. Of course, it would be nice if the hardware clock knew what the current offset is, then the issue would be easily and correctly solved.

BTW, I've always wondered about how the transition day is calculated. I've never been able to find a simple description of it. Most (all?) systems seem to know when it is, and it allways seems to be correct (for US timezones excluding Indiana), but I can't see how it could be 'calculated' from a simple rule that doesn't need to be updated from time to time. The TZ variable indicates whether the zone has DST and what the offset change is, but it doesn't have any information about when the change is. Is it just a 'last Sunday in October/April' or something like that hard coded in the library?

UTC

[mirabilos]

Servers ought to use /usr/share/zoneinfo/right/UTC
anyways because of the logs and stuff, and me, being
consistent, despite living in right/Europe/Berlin zone,
switched all my clocks (server, desktop, notebook,
watch, wrist clock, microwave oven clock, car clock
etc.) to UTC. I just add the one or two hours in mind.

Maybe Linux/Unix/etc. should take notes from VMS

[moldar]

Having been involved in some Time Change projects at work I was impressed to hear how the VMS system handled the time change. Instead of having a big jump in the time they slew the clock over the course of 6-12 hours. That way it lets all the jobs run with times that are 'close enough' without having to worry too much about the special cases. Just my $0.02

Re:Wrong

[mvdwege]

I can corroborate the previous statements.

Although I am on Debian like the first two posters to reply, I did some more checking, and Debian installs vixie cron. AFAIK this is what most Linux distros install by default, including Red Hat, which I runned before this.

Would you mind telling us what distro you had to dig up to find this gem? They deserve to be rightly flamed (and by extension if you can't give a satisfactory answer, you deserve to be flamed).

Mart