Re: Received mail timestamp is off by 7 hours

From: Loren M. Lang (lorenl_at_alzatex.com)
Date: 03/02/05

  • Next message: Kris Kennaway: "Re: referencing in files" 
    Date: Wed, 2 Mar 2005 02:29:08 -0800
To: Ian Smith <smithi@nimnet.asn.au>

    On Tue, Mar 01, 2005 at 02:22:40AM +1100, Ian Smith wrote:
    > On Mon, 28 Feb 2005 03:36:41 -0800 Loren M. Lang wrote:
    > > On Mon, Feb 28, 2005 at 12:58:17AM +1100, Ian Smith wrote:
    > > > On Sun, 27 Feb 2005 03:10:12 -0700 Pat Maddox <pergesu@gmail.com> wrote:
    > > >
    > > > > Alright, I got it all working now. Not sure how to change the time
    > > > > zone with config files, so I just used sysinstall to change it to MST
    > > > > (time zone is arbitrary, but since this is the zone I live in, it's
    > > > > convenient for me). Then I used ntpdate to sync it, and it's working
    > > > > well now.
    > > > >
    > > > > Thanks for pointing that out to me. I just thought that CET was central time :)
    > > >
    > > > Yes sysinstall's as good a way as any, it'll set your timezone and also
    > > > let you choose between running with a UTC or local time CMOS clock. Or
    > > > you can manually tun tzsetup(8) and create (or not) /etc/wall_cmos_clock
    > > > .. see adjkerntz(8)
    > > >
    > > > Take little notice of people opining that you must or even should run
    > > > CMOS UTC time; that's entirely up to you. I've always preferred local
    > > > time CMOS clocks personally; sysinstall creates /etc/wall_cmos_clock and
    > > > cron runs 'adjkerntz -a' halfhourly at times when daylight savings time
    > > > might come or go in your zone, and that's always worked fine here.
    > >
    > > The reason using UTC for the cmos clock is that it never changes like US
    > > daylight savings does. Now if your timezone doesn't ever need to be
    > > pushed forward or backwards then it won't be a problem, but otherwise
    > > evertime the system boots up, it has to determine if the cmos time is
    > > correct or needs to be adjusted. A UTC time will always be correct and
    > > can be turned exactly into the correct time at the moment. I think that
    > > if FreeBSD crashed just after it booted up and adjusted the hour forward,
    > > then on the next reboot, it would adjust it another hour forward. In
    > > general, it is just harder to manage. Even worse would be my Quad boot
    > > system with Gentoo Linux, FreeBSD, OpenBSD, NetBSD. If I used local
    > > time for my cmos clock then every daylight savings change, each os would
    > > adjust the clock independently and I'd be 3 hours off.
    >
    > I don't believe that's correct Loren, at least, not for FreeBSD anyway.

    Well, I haven't looked into all the details of how FreeBSD does this,
    but I gaurentee that there is a point where FreeBSD can crash and the
    clock could be knocked off an hour which wouldn't happen if it's running
    UTC. Though this window could just be a matter of seconds, I'm not
    sure. Also multi-booting multiple OS's with it set to local time will
    always be a problem unless you set only one os to update the clock, and
    even then, while running the other oses, the update will never happen
    until you boot into the os which does it. But, in general, it is just a
    little bit less reliable using local to UTC unless you are not affected
    by any daylight savings changes like Arizona in the US or, I'm sure, many
    other places around the world.

    <snip> 

    -- 
I sense much NT in you.
NT leads to Bluescreen.
Bluescreen leads to downtime.
Downtime leads to suffering.
NT is the path to the darkside.
Powerful Unix is.
Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc
Fingerprint: CEE1 AAE2 F66C 59B5 34CA  C415 6D35 E847 0118 A3D2
 
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"
  • Next message: Kris Kennaway: "Re: referencing in files"

    Relevant Pages

    • Re: Received mail timestamp is off by 7 hours
      ... > The reason using UTC for the cmos clock is that it never changes like US ... > time for my cmos clock then every daylight savings change, ... move the kernel clock to UTC; otherwise it takes CMOS clock time as UTC. ...
      (freebsd-questions)
    • Re: Received mail timestamp is off by 7 hours
      ... > let you choose between running with a UTC or local time CMOS clock. ... The reason using UTC for the cmos clock is that it never changes like US ... it would adjust it another hour forward. ... Bluescreen leads to downtime. ...
      (freebsd-questions)
    • Re: system time wrong
      ... NTP is UTC only, and has no concept of timezones, much less daylight ... savings times. ... suggests it is something to do with daylight savings. ... system time, it puts the PHP web applications 1 hour in the future! ...
      (alt.os.linux.suse)
    • Re: [PHP] Time-Zone juggling
      ... > Does Daylight Savings alter Zulu time? ... UTC does not observe Daylight Savings Time. ... Another option would be to store epoch time (seconds since the OS's ...
      (php.general)
    • Re: UTCNow <> GMT
      ... Unfortunately this wasn't the case as the timing was ... know it was in daylight savings. ... timezone while UTC is more likely a baseline for sharing time amone world. ... When it comes to a Windows OS, GMT is a time zone and UTC is not. ...
      (microsoft.public.dotnet.languages.vb)