Slashdot Mirror
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?"
considering i never wind my (analog) watch back or forward, why should i expect my computer to do any better?
gus
P.S. Get to it, linux guys ... maybe I will have a look.
.. if only.
My experience is that UNIX displays the incorrect time in any case, if you forget to update it from the hardware clock at every reboot. I have hwclock -s in rc.local when I feel like it. This happens regardless of the settings in the kernel (the APM settings).
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.
Is your browser retarded?
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:
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.
Why not let us read it? Maybe it would help out some other people.
But you are right about databases. Most DBAs( that I have worked with ) are not away of the TZs effect on the database.
for using daylight saving time. Come to Indiana, where people are more normal, and don't try to change time itself.
"Are even technical users ignorant on how UNIX handles time, time zones, and time conversion?"
Why are you asking here at slashdot about the knowledge of technical users?
I can recall some really screwy things happening to make if you muck around with date -s as root. Stale files being up to date, other files being created in the future. I'd imagine Daylight Savings would be similar in some ways.
Isn't there some standard we could all agree upon, such as dates and times will be translated at submission time into GMT and cron jobs be run at whatever local time maps to the corresponding GMT? Then, if you want make local time jump around, fine, it's your own responsibility if you like discontinuous time (kind of like heavy drinking).
There's still probably room for ambiguity with all these "leap seconds" I keep hearing about...
"Provided by the management for your protection."
Why not just run an NTP client on the box? Then you get accurate time and spring/fall time changes automatically.
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.
Tarsnap: Online backups for the truly paranoid
Are even technical users ignorant on how UNIX handles time, time zones, and time conversion?
/etc/default/init and reboot!
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
Just have your company relocate to Indiana. We don't need no steenking daylight savings.
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.
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.
This sig no verb.
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?
According to most things I've read, computers that count upwards from 1970 are doomed to have their date information run out in the year 2030. Has any though been made about how that conversion is going to be made?
One thing about the whole Y2K thing--proves just how into themselves geeks are. Uber programmers were going on about a post-apocalyptic type situation, but even in developed countries where little or no Y2K fixes were made, things went just fine.
Karma: Chevy Kavalierma.
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.
Esli epei etot cumprenan, shris soa Sfaha.
I was the AC who originally submitted the article. (I had to AC to remove any connection with my company, which wouldn't have authorized asking in public with their name attached.)
I think the greatest surprise here is that cron behavior is inconsistant across platforms. The systems I looked at did the twice-or-never routine. (I did come across an old bug in BSG that did a twice-or-once instead!)
But I think it is important to understand how, not only is there a problem in the way people perceive that cron handles it, but that it handles it differently here and there. It certainly makes the problem messier. You'd think it would be standardized.
Never changed times, never will.
I don't understand this stupidity of daylight savings time. Just accept it...during the Winter, Sunrise is at 8am, Sunset at 6pm and during the Summer, Sunrise is at 5am, Sunset at 9pm. Accept nature's natural cycle. Don't start f**king with the clocks to make it appear that you somehow have more daylight now...you don't!
Thomas Dz.
> 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.
If you are storing time_t in files as an int you deserve what you will get.
> 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.
About one. The problem, if any, is trivial compared to the COBOL one.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
And what about those who store time_t as a time_t? On the systems I've seen, time_t is a long, which is most often 32 bits. Setting up a file format around that seems the "obvious" thing to do.
While it's true that thinking ahead makes sense, people tend not to do so if the "obvious" solution works (and will continue to work for over thirty years, by which time they hope they'll be retired).
I'd not be so sure. I can well imagine that in a bunch of places, there's just not enough space to store the extra bits, just as in the Y2K problem people had to scare up an extra two bytes in all sorts of places to store the century... which is not so good in, say, protocols which have fixed field widths. I don't think it's something trivial which can be fixed by just recompiling everything (which in itself is not trivial -- you'd really need to test the software all over again to check that you didn't break anything by compiling with wider integers).
Esli epei etot cumprenan, shris soa Sfaha.
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!!!
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.
My Karma isn't excellent, damn it! (And
Not correct. Indianans all set their clocks to GMT minus 5 hours. Solar time for Indiana is closer to GMT minus 6 hours, with a 20 minute variation from east to west (unless I've screwed up the math, entirely possible). Like everybody else in this industrial age, Indianans ignore the sun and use a convenient time standard instead. The Indianan standard is just a little simpler than most.
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.
Most file formats that I've seen (such as OpenPGP), define the time as a 4 byte UNSIGNED value, which will work until 2106 (if I'm calculating that correctly). The odds that any file formats today will be in use by then is pretty freaking small. Anyway, I'll be 125 (long retired or long dead) at that point, so I'm not worried.
In fact there is no problem with defining time_t as an unsigned int. time()'s is defined as returning (time_t)-1 on error -- this works regardless of time_t's signedness.
Are even technical users ignorant on how UNIX handles time, time zones, and time conversion?
Yes, so share your report with us, at least summerize it.
Will simply avoiding scheduled jobs between 2 and 3am solve most of our problems?
-Bill
SlashSig Karma: Excellent (mostly affected by moderatio
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
Hmm...
1) systems using a signed 32 bit (31 bit effective) offset in seconds from Jan 1 1970 GMT will overflow around 2030.
2) 32 bit systems will hopefully be rare enough by that time that using a 64 bit offset will be cheap
3) The Y2K scare was more of a media, grandma-watching-CNN, and expensive COBOL analyst driven thing than a geek thing. I made several bets with less informed people that there would be no problems worth noting... I never got my money.
He answered "yes" but became rather less impressed an hour later when, once again, it asked him if the clock should be reset. For fun he kept answering yes each hour till he was done with his article.
Database, cron and other timezone problems aside, at least a properly set up *nix always knows what time it is both locally and in UTC so the other programs at least have a shot at running properly.
~~~~~~~
"You are not remembered for doing what is expected of you." - Atul Chitnis
Unix/Linux can do this with adjtime, but for daylight saving time that seems like the wrong behavior. This is normally how things like ntp keep the systems time in check without having jumps.
But, daylight saving time is really a jump and I wouldn't want my clock to say 8:30PM at 8:00
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
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)
Like Arizona. None of that wishy-washy part of the state does one thing, part of the state does another. It's no daylight saving for ANYONE! Half the cheer, you chill with the other Mountain TZ'ers, and then, they all shift, and you're left chilling with the Pacific. It's all good!
Oh, except for the fact it really screws up TV schedules. You never have any idea when any cable program will actually be on.
Yeah, you Indiana people are really cutting edge.
I moved to Indiana a year ago after living my entire life in DST zones, and I thought not having to worry about DST would be nice.
But it's actually weirder because the rest of the (preceived) world goes on DST.
Sporting events happen at different times, TV shows air at different times (and there is discrepancy between cable & broadcast times), and scheduled work conference calls change times.
If you think forgetting to set one or two of your clocks back is a pain, try having half of your daily schedule change times and keep straight what changes and what doesn't.
As far as the article goes, admins may not need to understand the technical details of what cron does two hours out of every year, but they sure as hell had better know if their backups and periodic maintenance is getting done!
Then again in cases I've worked missing one backup wouldn't be critical.
Oh sure, it's still 7998 years away, and that SEEMS like a really long time, but it's really not. Pretty soon, it'll be 9999 and everyone will be running around looking for COBOL programmers who can update their software to support 5 digit years.
man 3 time
man localtime
man tzset
Download the Zoneinfo source from ftp://elsie.nci.nih.gov/pub
You'll need to grab the latest versions of tzcode and tzdata. Just read the docs and source comments to learn more about time zones and daylight savings than any right thinking person would ever need/want to know.
Now wash your hands.
Writing a report on Day Light Savings Time, well either your company has nothing for you to do, or you finish your work way to quickly.
We should be moving the clock forward in Fall and back in Spring. I fucking hate sunlight in the morning and having it taken away from me in the evening. I rather like waking up and going to work in the dark. Plus, the more light I have in the evening, the longer I can ride my bike. Why are we doing it backwards?
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.)
i know plenty of people out of work that would love to see an increase of systems here =)