Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Unix Operating Systems Software

Daylight Savings and UNIX? 94

Posted by Cliff from the it's-not-as-easy-as-you-think dept.
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?"
This discussion has been archived. No new comments can be posted.

Daylight Savings and UNIX? More

Daylight Savings and UNIX?

Comments Filter:

  • DST? (Score:2, Insightful)

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

  • Wrong (Score:5, Insightful)

    by gus goose ( 306978 ) on Thursday October 10, 2002 @08:33AM (#4422911) Journal
    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 (Score:5, Informative)

      by JimR ( 101182 ) on Thursday October 10, 2002 @08:44AM (#4422973) Homepage

      Hmmm... this is what man cron gives on my Debian [debian.org] 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 (Score:4, Funny)

      by Col. Klink (retired) ( 11632 ) on Thursday October 10, 2002 @08:45AM (#4422974)
      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 (Score:4, Interesting)

      by mvdwege ( 243851 ) <mvdwege@mail.com> on Thursday October 10, 2002 @04:28PM (#4427119) Homepage Journal

      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 (Score:5, Insightful)

    by Clue4All ( 580842 ) on Thursday October 10, 2002 @08:55AM (#4423027) Homepage
    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 (Score:5, Insightful)

      by Covener ( 32114 ) on Thursday October 10, 2002 @10:08AM (#4423547)
      Technical users know UNIX systems should keep their hardware clocks in UTC, but should obviously be aware of timezones and local time.

      • Dual boot? (Score:3, Interesting)

        by Gerry Gleason ( 609985 )
        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?

        • Re:Dual boot? (Score:3, Informative)

          by lewiscr ( 3314 )
          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 [webexhibits.org] has history and start/stop days by country.

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

        • The day is set arbitrary by some committee or other for the next few years. AFAIK, talks are in progress to drop the whole braindead idea of daylight for good, next time around...

  • Varies depending on which "cron" (Score:5, Informative)

    by shoppa ( 464619 ) on Thursday October 10, 2002 @09:06AM (#4423109)
    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 [fcron.free.fr]. 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.

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

  • I guess that's what you get.... (Score:3, Funny)

    by eclectric ( 528520 ) <bounce@junk.abels.us> on Thursday October 10, 2002 @09:28AM (#4423245)
    for using daylight saving time. Come to Indiana, where people are more normal, and don't try to change time itself.
    • Come to Indiana, where people are more normal, and don't try to change time itself.
      I always heard that (most of) Indiana didn't change the clocks because they thought it would confuse the cows...
      • 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".

        • Re:I guess that's what you get.... (Score:4, Insightful)

          by crath ( 80215 ) on Thursday October 10, 2002 @10:32AM (#4423709) Homepage
          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."
          • I'd appreciate a link to that, but it probably won't sway me. After all, what about the thousands who will die because we'd be taking away their benchmark for smoke alarm battery changing... ;-)

            (Seriously though, a link or two would be cool, google didn't turn up anything interesting so I'm wondering if you got scammed. I only found a single reference to a 7% increase in 'the monday after the april change' traffic accidents, but that certainly wouldn't account for "a few thousand people" nor was the reference any kind of controlled study that would include the costs of increased pollution, kids getting hit in the dark walking to and fro school and the rest of the flavor of thing)

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

            Indeed! We should ask those people to get a good nights rest before driving to work Monday morning!

            Oh, I guess that's not what you meant. I suppose personal responsibility is only useful when it supports *your* argument. ;-)
      • Actually we subscribe to newtonian physics. Time is constant. This is a step forward from when the legislature declared PI to be 3.

        I personally think that everyone should switch to GMT. Why should everyone in the country wake up at 6 am local time anyway?

        Joe
        • Why should everyone in the country wake up at 6 am local time anyway?

          because it would be very confusing to have a day change 3 hours waking up? Or in the middle of lunch...
          • In college, I often worked through the change of the day. It wasn't nearly as confusing as figuring out what time it is in California when you live in Indiana.

            I would know that it is 19:21 Oct 10 and that my friend in California gets to work at 19:00 GMT and leaves at 3:00 GMT the next day.

            Joe
    • Um. BZZZT! Different parts of Indiana are in different time zones and some of those parts do observe DST. (reference [timetemperature.com]). 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.
    • 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.
    • Come to Indiana, where people are more normal, and don't try to change time itself.

      Yeah, just fundamental mathematical constants [straightdope.com].

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

    • Re:date -s (Score:3, Insightful)

      by duffbeer703 ( 177751 )
      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.

  • NTP (Score:2, Informative)

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

    • Re:NTP (Score:4, Informative)

      by BlueUnderwear ( 73957 ) on Thursday October 10, 2002 @04:41PM (#4427263)
      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.

  • In FreeBSD... (Score:5, Interesting)

    by cperciva ( 102828 ) on Thursday October 10, 2002 @10:14AM (#4423580) Homepage
    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.
    • Also, in FreeBSD you get a choice of whether to handle changes in GMT offset in an intelligent way or not. -o gives the old behaviour, -s makes it smart.

  • Time zones (Score:3, Informative)

    by sql*kitten ( 1359 ) on Thursday October 10, 2002 @10:19AM (#4423628)
    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:Time zones (Score:2, Insightful)

      by bbc22405 ( 576022 )
      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.

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

        Unfortunately, it's a test rig for a date and locale sensitive application - timezone needs to be changed frequently system-wide as part of testing (the machines themselves are physically static :-) ).

  • Daylight Savings? Blech (Score:4, Funny)

    by Eponymous, Showered ( 73818 ) <jase&dufair,org> on Thursday October 10, 2002 @10:23AM (#4423660) Homepage
    Just have your company relocate to Indiana. We don't need no steenking daylight savings.
    • We don't need no steenking daylight savings.
      Too bad part of Indiana observes DST and part of it doesn't, which just makes things even more confusing.
    • or Arizona or Hawaii.
    • Move to Indiana? That's the most DST-schizo state in the U.S.! Most of the state follows EST, but the area near Chicago and around Evansville, IN is in Central time. And other sections near Ohio and Kentucky are in Eastern time (including EDT during the summer). Move to Arizona or Hawaii.
    • 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.

  • Grammar Nazi Time (Score:4, Informative)

    by zsazsa ( 141679 ) on Thursday October 10, 2002 @10:53AM (#4423838) Homepage
    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 [nist.gov] says so.

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

  • Not really unaware (Score:2, Informative)

    by dacarr ( 562277 )
    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.

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

    • Re:The Y2030 "Bug" (Score:3, Informative)

      by pne ( 93383 )

      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.

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

        • If you are storing time_t in files as an int you deserve what you will get.

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

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

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

  • OpenBSD cron (Score:1, Informative)

    by 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!!! :)

  • UTC (Score:3, Interesting)

    by mirabilos ( 219607 ) on Thursday October 10, 2002 @01:17PM (#4425239) Homepage
    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.
    • in the states, it's a little trickier, as we aren't just one or two off, but a full 5-8. it's annoying to work with the numbers from that. one or two are easy, more than 4 is difficult for me (i spent the summer in Europe, being able to go from greece to france with only one hour's difference was nice).

  • Yes (Score:2)

    by wdr1 ( 31310 )
    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

    • Will simply avoiding scheduled jobs between 2 and 3am solve most of our problems?

      If your goal is to avoid the DST crossover, you should avoid 1am to 3am because it changes from 2am to 3am in the spring and from 2am to 1am in the fall.

  • 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
    • 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

  • Windoze (Score:3, Funny)

    by linuxwrangler ( 582055 ) on Thursday October 10, 2002 @04:14PM (#4427019)
    All this reminds me of the guy doing a writeup on the then-new Windows 95 years ago. He was apparently trying to get his article in on deadline when it became time to "fall back". He wrote that he was impressed by the fact that Windows told him that the time had changed back and asked if he wanted the computer's clock reset.

    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.

  • 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)

  • 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.
  • 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?
  • 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.)

Slashdot Top Deals

Happiness is twin floppies.

Close