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

DST?

[lburdet]

considering i never wind my (analog) watch back or forward, why should i expect my computer to do any better?

Wrong

[gus goose]

This is taken from the HP Cron man page.

Spring and Autumn Time Transitions
On the days of daylight savings (summer) time transition (in time zones and countries where daylight savings time applies), cron schedules commands differently from normal. In the following description, an ambiguous time refers to an hour and minute that occurs twice in the same day because of a daylight savings time transition (usually on a day during the Autumn season). A nonexistent time refers to an hour and minute that does not occur because of a daylight savings time transition (usually on a day during the Spring season). DST-shift refers to the offset that is applied to standard time to result in daylight savings time. This is normally one hour, but can be any combination of hours and minutes up to 23 hours and 59 minutes (see tztab(4)). When a command is specified to run at an ambiguous time, the command is executed only once at the first occurrence of the ambiguous time. When a command is specified to run at a nonexistent time, the command is executed after the specified time by an amount of time equal to the DST-shift. When such an adjustment would conflict with another time specified to run the command, the command is run only once rather than running the command twice at the same time. Commands that are scheduled to run during all hours (there is a * is in the hour field of the crontab entry) are scheduled without any adjustment.

This is taken from the Linux cron manpage though:

Note that this means that non-existant times, such as "missing hours" during daylight savings conversion, will never match, causing jobs scheduled during the "missing times" not to be run. Similarly, times that occur more than once (again, during daylight savings conversion) will cause matching jobs to be run twice.

So, if you want things to work, use HP-Unix.

gus

P.S. Get to it, linux guys ... maybe I will have a look.

Nope

[Clue4All]

Are even technical users ignorant on how UNIX handles time, time zones, and time conversion?

Nope, technical users know that UNIX systems should be run using GMT, which doesn't observe daylight savings time.

Re:Nope

[Covener]

Technical users know UNIX systems should keep their hardware clocks in UTC, but should obviously be aware of timezones and local time.

Re:I guess that's what you get....

[crath]

It's sad to hear that Indiana may bow to peer pressure from the rest of the world w.r.t. Daylight Savings Time (DST). There have been a number of very credible studies done over the past decade, and DST costs lives (and money) due to the manner in which it disrupts our body clock.

The grand hypocracy of the whole DST gambit is the DST supporters' claim that the energy savings justify DST; i.e., let's annually sacrifice a few thousand people to save a bit of energy.

If DST supporters truly want to put an open and honest argument on the table for their position, their cost-benefit analysis needs to account for the lost lives, lost quality of life due to personal injuries, lost productivity, lost monies, etc., in addition to tallying up the energy savings and extra time spent on the golf course.

Why is it too much to expect that people turn their brains on, fire a few neurons, and produce cogent thought? DST is yet another example of, "It *feels* good so it must the right thing to do."

Re:date -s

[duffbeer703]

The world already has a standard -- UTC.

System time should be set to UTC, and the time display should be seperate configuration step.

Using NTP should take care of the leap second problem, as long as your Stratum-1 server is accurate.

You guys are confused... UNIX always uses GMT (1)

[m.dillon]

Internally UNIX always uses GMT (1), period. time() always returns epoch time. It is not effected by daylight savings time or zone changes. NTP keeps epoch time in synch. It is not effected by daylight savings time or zone changes either.

Your time zone preference can be set on a shell-by-shell basis or process-by-process basis using the TZ environment variable. The system has a default preference that is typically /etc/localtime. In short, the system doesn't care what your preference is. The preference only effects display representations, it does not effect the underlying timekeeping.

Programs can choose to use whatever timezone they wish independant of any preference. It just so happens that cron defaults to using the system local time preference but nothing prevents you from changing that if you don't like it. In fact, many cron's allow you to set the time zone you want to specify your jobs in on a user-by-user basis. So if cron's skipping around is bothering you, just switch it to GMT (1).

(note 1: well, it's either GMT or UTC, I forget which. There are subtle differences)

Re:Time zones

[bbc22405]

But if you want to change the timezone globally, for running processes, you can't because time zone comes from init - at the very least you have to stop and restart processes after setting TZ, and if you're going to do that, you might as well edit /etc/default/init and reboot!

If your Unix box is wandering about the globe, powered, running, changing timezones willy-nilly, please do consider selecting some sort of generic time zone for the system, one that you won't feel compelled to change system-wide. Other people have mentioned GMT and UTC.

For the user, simply changing the TZ variable should mostly have the desired effect.