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

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.

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.

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

[rw2]

confuse the cows

Smirk. My uncle works in state government in Indiana and I tease him about this from time to time. He's been around long enough to remember the debate on this one and he says that *one* of the reasons that they don't switch is because the drive-in-movie theaters had a strong lobby the last time this was seriously discussed.

That always cracks me up. The entire state is out of step with their neighbors because of theater owners.

They are considering changing to a more conventional (notice I didn't say 'normal', just conventional) system and he says "I don't think that lobby is as strong as it used to be".

NTP

[stu72]

Why not just run an NTP client on the box? Then you get accurate time and spring/fall time changes automatically.

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.

Time zones

[sql*kitten]

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

Maybe this has been fixed by now (AFAIK as of SunOS 5.8 it hasn't) but Unix' handling of timezones has always been pretty lame. For example, if you want to change timezone in your shell (and for processes subsequently spawned) you just set the TZ environment variable. If you want to change the system time globally, su to root and use the date command, and running processes will see it next time they ask the OS for the time. OK so far. 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!

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

[ichimunki]

Um. BZZZT! Different parts of Indiana are in different time zones and some of those parts do observe DST. (reference). In fact, of all the states, Indiana is probably the worst in this respect. If you have trouble dealing with clocks, the place to be is Arizona.

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.

Not really unaware

[dacarr]

I learned to be aware of the problem the hard way one year. I had adjusted PDT->PST on my watch in 1998 at 00:30 PDT, making it 23:30 on my watch again. The problem remained when I had forgotten to adjust the day back one increment, so when Tuesday came around (the day I was to go back to work), I had thought I missed a day of work.

Now I am very careful about what cron jobs I run between 01:00 and 03:00 on any unix box (they might check for the existance of something at most), and accordingly leave ntpd running.

Re:The Y2030 "Bug"

[pne]

2038 is more like it. 03:14:07 UTC on 19 January 2038, to be exact.

And no, just hoping everyone's going to be running 64-bit systems by then is not going to help if you have, for example, file formats which only allocate 4 bytes to storing a time_t value.

I'll not have reached retirement age in 2038... I wonder how many C programmers will be called out of their holes to patch programs similar to the hunt for COBOL experts at the end of last century.

Re:=P abcd1233243459834982

[Anonymous Coward]

...sounds like someone doesn't have their daylight savings time rules or timezone set correctly. Does "TZ" ring any bells?

Re:Dual boot?

[lewiscr]

BTW, I've always wondered about how the transition day is calculated. I've never been able to find a simple description of it.
*snip*
Is it just a 'last Sunday in October/April' or something like that hard coded in the library?

Depends on the Country and the Hemisphere. The US (and most of North America) is first sunday in April and last sunday in Octoboer. I didn't realize that the Southern Hemisphere observers DST the other six months (ie, their summer). Seems obvious in hindsight.

Web Exhibits has history and start/stop days by country.

I shamelessly stole a bit of DST calculation code from their web site.

OpenBSD cron

[Anonymous Coward]

If time has moved forward, those jobs that would have run in the interval
that has been skipped will be run immediately. Conversely, if time has
moved backward, care is taken to avoid running jobs twice.

*BSD's rock!!! :)

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

[crath]

A couple of links:

Accident rates increase in response to DST---Stanley Coren of the University of British Columbia
UK government's Transport Research Laboratory numbers---the practice of turning the clocks back had led to 3,000 deaths on Britain's roads in the last 30 years

Lastly, my feel good comment was in relation to the extra hours spent on the golf course. It was a bit of a flame and I probaby should have deleted that comment before posting.

Daylight time doesn't matter with UTC

[ptudor]

Why bother worrying? Run your system using UTC entirely and just set the TZ variable in your shell. It's not really that hard to add or subtract an oftentime single digit number to find the time relative to you. (and when you're lazy, gdate -u is a quick doublecheck)

Other benefits of UTC? A central logserver taking logs from hosts across the continent. "Was that at 2 Central or Eastern? Wait, what time is it in Indiana right now?" Additionally, when you have users across the world it provides a common time. I've meet many people who thought that the common Eastern timezone was still EST in the summer and never used EDT. Once again, Indiana: in the summer, it's the same as CDT, but it's still EST (unless you're near a major city on a border, in which case the appropriate [CD]DT is used). Don't add this confusion to your system accounting.

Using UTC as a common reference time for computing devices simplifies the maintenance of them and eliminates any potential problems originating from the use of local daylight time.

heheh because I'm on Pacific time, all the cron mail sent out at midnight shows up early in the evening. A side benefit.

(And NTP! Please! Accurate time is key to accurate forensics in the event of an intrusion crossing multiple boxes. Even the MacOS and XP have built-in support.)