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

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.

Re:Wrong

[JimR]

Hmmm... this is what man cron gives on my Debian Linux box...

Special considerations exist when the clock is changed by less than 3
hours, for example at the beginning and end of daylight savings time.
If the time has moved forwards, those jobs which would have run in the
time that was skipped will be run soon after the change. Conversely,
if the time has moved backwards by less than 3 hours, those jobs that
fall into the repeated time will not be re-run.

Only jobs that run at a particular time (not specified as @hourly, nor
with '*' in the hour or minute specifier) are affected. Jobs which are
specified with wildcards are run based on the new time immediately.

Clock changes of more than 3 hours are considered to be corrections to
the clock, and the new time is used immediately.

Re:Wrong

[Col. Klink (retired)]

From my Debian Woody cron man page:

Special considerations exist when the clock is changed by less than 3 hours, for example at the beginning and end of daylight savings time. If the time has moved forwards, those jobs which would have run in the time that was skipped will be run soon after the change. Conversely, if the time has moved backwards by less than 3 hours, those jobs that fall into the repeated time will not be re-run.

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

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.

Varies depending on which "cron"

[shoppa]

There are multiple cron-type systems out there.

Many Linux distributions ship with a heavily (and I mean heavily) patched up version of Vixie-cron as the default cron package. This is what many people refer to in this thread when they say "Linux cron".

There are other cron packages out there for Linux; for example, fcron. Section 2.2 of the fcron FAQ says:

First, you must understand that fcron determines, for each job, its next time and date of execution. It then determines which of those jobs would be the next to run and then, sleeps until that job should be run. In other words, fcron doesn't wake up like Vixie cron each minute to check all job in case one should be run ... and it avoids some problems associated with clock adjusts.

This means that if the new time value is set into the past, fcron won't run a particular job again. For instance, suppose the real time and system clock are 3:00, so the next job cannot be scheduled to run before 3:00, as it would have already been run and re-scheduled.

First, suppose you set your system clock into the past, say to 2:00, Presuming that the last run was shortly before 3:00. then fcron will sleep until the next job should be executed. The execution time for a job is determined by identifying the last time that the job ran and computing the next scheduled time. This means that the next scheduled time must be on or after 3:01. Therefore, in this example, fcron will not run a job for at least one hour.

Next, if you set the system time into the future, say to 4:00, fcron will run every job scheduled between the old and the new time value once, regardless of how many times it would have been scheduled. When fcron wakes up to run a job after the time value has changed, it runs all the jobs which should have run during the interval because they are scheduled to run in a past time.

As special case is when "@xxx" style scheduling rules are involved, you must consider the "adjustment-interval". The "adjustment-interval" is the time difference between the original system time and the new system time. If the ... run at "adjust-interval" too early or too late depending of the nature of the adjust.

To conclude, fcron behaves quite well for small clock adjusts. Each job which should have run does so once, but not exactly at the correct time as if the job were scheduled within the adjustment interval. But, if you have to make a big change in the time and date, you should probably reset all the scheduled "nextexe" by running "fcrontab -z" on all the fcrontabs.

And to further complicate matters, most commercial Unix-type OS's are either completely independent of Vixie-cron or they genetically "diverged" from Vixie-cron so long ago that they bear only faint resemblance to the original.

Maybe those technical people who you are questioning worked on a non-Linux system that doesn't suffer from the idiosyncrancies of Vixie-cron, or maybe they use fcron.

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.

Daylight Savings? Blech

[Eponymous, Showered]

Just have your company relocate to Indiana. We don't need no steenking daylight savings.

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

Grammar Nazi Time

[zsazsa]

Okay, this has to be the absolutey most assinine thing I've done on Slashdot, but I've gotta do it.

It's daylight saving time, not daylight savings time. NIST says so.

Anyway, if it were up to me, we wouldn't have daylight saving at all.

Re:NTP

[BlueUnderwear]

Why is this drivel moderated at 4?

First, NTP does not affect spring/fall time "changes" at all. Regardless of whether you have NTP or not, this "change" happens correctly. Indeed, daylight saving time only affects how time is displayed (or broken up in day, hour, minute, second), and does not affect the physical clock at all (which is kept in UTC at all times). NTP however, ensures accuracy by synching the physical clock (kept in UTC) to a master.

Moreover, the subject of this discussion is not the accuracy of the displayed time, but rather how cron (which works in local time) copes with with "duplicate" and "missing" hours. Installing NTP does nothing to help this, only picking the right cron works. Or just use the commonsense solution of not scheduling any important jobs between 2am and 3am.