Kernel Time and DST - Questions

This is a discussion on Kernel Time and DST - Questions ; I had RH9 installed this summer on my system. Ever since the change from DST to normal time there had been a problem with the kernel time. This is what happens. I boot up the system. Checking the BIOS settings, ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Kernel Time and DST

  1. Kernel Time and DST

    I had RH9 installed this summer on my system. Ever since the change from
    DST to normal time there had been a problem with the kernel time. This is
    what happens.

    I boot up the system. Checking the BIOS settings, the hw clock says the
    correct time, say 10:00. I am on CET, which is UCT+1.

    When the kernel boots up it says:
    Setting clock (localtime) : 10:00 UCT
    After boot has finished, date says: 11:00 CET, which is wrong.

    I tried setting TZ=Europe/Zurich in rc.sysinit, just before the hwclock
    call. Looking at the hwclock arguments, they are: --localtime --hctosys.
    Debug output from hwclock says that minadjust is -60min, which is
    correct.

    Furthermore, after booting has finished, calling hwclock with the same
    arguments gives me the correct time. I have no idea why the time is
    incorrect when the kernel boots up and yet it is correct afterwards. Can
    someone help?

    Cheers, Christos

    --
    Christos Dimitrakakis
    IDIAP (http://www.idiap.ch/~dimitrak/main.html)

  2. Re: Kernel Time and DST

    Christos Dimitrakakis wrote in message news:...
    > I had RH9 installed this summer on my system. Ever since the change from
    > DST to normal time there had been a problem with the kernel time. This is
    > what happens.
    >
    > I boot up the system. Checking the BIOS settings, the hw clock says the
    > correct time, say 10:00. I am on CET, which is UCT+1.
    >
    > When the kernel boots up it says:
    > Setting clock (localtime) : 10:00 UCT
    > After boot has finished, date says: 11:00 CET, which is wrong.
    >
    > I tried setting TZ=Europe/Zurich in rc.sysinit, just before the hwclock
    > call. Looking at the hwclock arguments, they are: --localtime --hctosys.
    > Debug output from hwclock says that minadjust is -60min, which is
    > correct.
    >
    > Furthermore, after booting has finished, calling hwclock with the same
    > arguments gives me the correct time. I have no idea why the time is
    > incorrect when the kernel boots up and yet it is correct afterwards. Can
    > someone help?
    >
    > Cheers, Christos


    Your last paragraph confused me just enough to refrain from giving an explanation.

    $ man hwclock

    You'll find it one of the most complete, understandable man pages on your system.

    HTH,
    prg
    email above disabled

  3. Re: Kernel Time and DST

    On Tue, 16 Dec 2003 04:23:56 +0100, P Gentry wrote:

    >>

    > Your last paragraph confused me just enough to refrain from giving an
    > explanation.
    >
    > $ man hwclock
    >


    I have read the manpages, thank you. Perhaps my last paragraph was indeed
    confusing. But what is happenning is quite strange, so let me rephrase
    it:

    System powers on - BIOS says the correct time (say 10:00).
    Linux kernel starts up. We are now in rc.sysinit:
    /sbin/hwclock --localtime --hctosys is invoked.
    According to the debug output, the hwclock is on 1000 CET.
    The date command, immediately afterwards in rc.sysinit displays:
    16 Dec 10:00 (CET)
    Kernel finishes booting. I login and type:
    > date

    16 Dec 1100 (CET)

    That's weird. I type
    > /sbin/hwclock --localtime --hctosys
    > date

    16 Dec 1000 (CET)

    Weird again. It seems like something changes the sysclock between the first
    invocation of hwclock in rc.sysinit and when booting has finished.

    PS. And a small note on the rc.sysinit file. Currently, just before the
    hwclock invocation, I have
    export TZ='CET'

    If I don't add this line, then the date command in rc.sysinit displays:
    16 Dec 10:00 (UCT)
    Initially I thought this was the source of my problem, so that's why I
    set the TZ variable. However it seems to make no difference whatsoever.
    There is something else that changes the date between the hwclock
    invocation and when the login prompt appears, though I have no idea what
    it is.



    --
    Christos Dimitrakakis

  4. Re: Kernel Time and DST

    Christos Dimitrakakis wrote in message news:...
    > On Tue, 16 Dec 2003 04:23:56 +0100, P Gentry wrote:
    >
    > >>

    > > Your last paragraph confused me just enough to refrain from giving an
    > > explanation.
    > >
    > > $ man hwclock
    > >

    >
    > I have read the manpages, thank you. Perhaps my last paragraph was indeed
    > confusing. But what is happenning is quite strange, so let me rephrase
    > it:
    >
    > System powers on - BIOS says the correct time (say 10:00).
    > Linux kernel starts up. We are now in rc.sysinit:
    > /sbin/hwclock --localtime --hctosys is invoked.


    which sets your Linux system clock to the BIOS (or CMOS or whatever
    you want to call it -- the clock on your motherboard)

    > According to the debug output, the hwclock is on 1000 CET.
    > The date command, immediately afterwards in rc.sysinit displays:
    > 16 Dec 10:00 (CET)


    which makes sense as your still using BIOS clock

    > Kernel finishes booting. I login and type:
    > > date

    > 16 Dec 1100 (CET)


    This is Linux system clock time -- no longer related to BIOS clock

    >
    > That's weird. I type
    > > /sbin/hwclock --localtime --hctosys


    You've just sent the BIOS clock time to the system clock

    > > date

    > 16 Dec 1000 (CET)
    >


    as shown here

    > Weird again. It seems like something changes the sysclock between the first
    > invocation of hwclock in rc.sysinit and when booting has finished.


    Yes, the system itself keeps it's own sense of the proper time and
    really doesn't use the BIOS clock for much of anything -- though on
    shutdown you'll likely see that hwclock --systohc has been invoked to
    help the BIOS clock stay better in sync with system clock. It's also
    quite handy for back dating Windows startups when you need extra time
    to eval one of those _stupid_ 7 day trials.

    >
    > PS. And a small note on the rc.sysinit file. Currently, just before the
    > hwclock invocation, I have
    > export TZ='CET'
    >
    > If I don't add this line, then the date command in rc.sysinit displays:
    > 16 Dec 10:00 (UCT)


    check man hwclock again to see how TZ and UCT relate (and how they
    don't)

    > Initially I thought this was the source of my problem, so that's why I
    > set the TZ variable. However it seems to make no difference whatsoever.
    > There is something else that changes the date between the hwclock
    > invocation and when the login prompt appears, though I have no idea what
    > it is.


    You may also need to check what's going on in the shutdown cycle and
    check your /etc/adjtime file to see what it says.

    Work your way through all the bits and pieces of info in man hwclock
    and write down what you expect to see before command -- issue command
    (and write down what you entered) -- write down the output/results.
    Any surprises? Perhaps try to set the BIOS clock a week ahead so that
    you can get some more obvious clues.

    Note this warning from the man page:

    The following options apply to most functions.

    --utc
    --localtime

    Indicates that the Hardware Clock is kept in Coordinated Universal
    Time or local time, respectively. It is your choice whether to keep
    your clock in UTC or local time, but nothing in the clock tells
    which you've chosen. So this option is how you give that information
    to hwclock.

    If you specify the wrong one of these options (or specify neither
    and take a wrong default), both setting and querying of the Hardware
    Clock will be messed up.

    If you specify neither --utc nor --localtime , the default is
    whichever was specified the last time hwclock was used to set the
    clock (i.e. hwclock was successfully run with the --set, --systohc, or
    --adjust options), as recorded in the adjtime file. If the adjtime
    file doesn't exist, the default is local time.

    Note that last paragraph!

    I'll also check into exactly how mine is set up sometime today.

    hth,
    prg
    email above disabled

  5. Re: Kernel Time and DST

    First of all, thank you for your replies. I have some extra comments..


    >> System powers on - BIOS says the correct time (say 10:00). Linux kernel
    >> starts up. We are now in rc.sysinit: /sbin/hwclock --localtime
    >> --hctosys is invoked.

    >
    > which sets your Linux system clock to the BIOS (or CMOS or whatever you
    > want to call it -- the clock on your motherboard)
    >
    >> According to the debug output, the hwclock is on 1000 CET. The date
    >> command, immediately afterwards in rc.sysinit displays: 16 Dec 10:00
    >> (CET)

    >
    > which makes sense as your still using BIOS clock
    >
    >


    Yes, the hwclock (or BIOS clock) is on 10:00 CET. And after I execute
    'hclock --localtime --hctosys', I check that the systime is correctly set
    with 'date'. This returns the correct time.

    Am I? This is after hwclock --localtime --hctosys
    So 'date', immediately aftewards, displays my sysclock time.

    >> Kernel finishes booting. I login and type:
    >> > date

    >> 16 Dec 1100 (CET)

    >
    > This is Linux system clock time -- no longer related to BIOS clock


    Indeed. However, in my previous invocation of 'date', the time was
    different. The following might explain the situation a bit better:

    When I'm in rc.sysinit I execute

    hwclock --localtime --hctosys.

    Then I execute 'date' which gives my the new sysclock time, which I have
    just set up from the BIOS clock. The date should not change anymore,
    since I have set it up already. Right?

    But when I finish booting the sysclock is one hour ahead, somehow (I
    check with 'date').

    Then, at the prompt I execute hwclock --localtime --hctosys again. I
    check the 'date' and it is now correct.

    That means that hwclock is working properly (I always call it with
    --localtime). So there is something else that messes things up...


    --
    Christos Dimitrakakis
    IDIAP (http://www.idiap.ch/~dimitrak/main.html)

  6. Re: Kernel Time and DST

    Christos Dimitrakakis wrote in message news:...
    > First of all, thank you for your replies. I have some extra comments..
    >
    >
    > >> System powers on - BIOS says the correct time (say 10:00). Linux kernel
    > >> starts up. We are now in rc.sysinit: /sbin/hwclock --localtime
    > >> --hctosys is invoked.

    > >
    > > which sets your Linux system clock to the BIOS (or CMOS or whatever you
    > > want to call it -- the clock on your motherboard)
    > >
    > >> According to the debug output, the hwclock is on 1000 CET. The date
    > >> command, immediately afterwards in rc.sysinit displays: 16 Dec 10:00
    > >> (CET)

    > >
    > > which makes sense as your still using BIOS clock
    > >
    > >

    >
    > Yes, the hwclock (or BIOS clock) is on 10:00 CET. And after I execute
    > 'hclock --localtime --hctosys', I check that the systime is correctly set
    > with 'date'. This returns the correct time.
    >
    > Am I? This is after hwclock --localtime --hctosys
    > So 'date', immediately aftewards, displays my sysclock time.
    >
    > >> Kernel finishes booting. I login and type:
    > >> > date
    > >> 16 Dec 1100 (CET)

    > >
    > > This is Linux system clock time -- no longer related to BIOS clock

    >
    > Indeed. However, in my previous invocation of 'date', the time was
    > different. The following might explain the situation a bit better:
    >
    > When I'm in rc.sysinit I execute
    >
    > hwclock --localtime --hctosys.
    >
    > Then I execute 'date' which gives my the new sysclock time, which I have
    > just set up from the BIOS clock. The date should not change anymore,
    > since I have set it up already. Right?
    >
    > But when I finish booting the sysclock is one hour ahead, somehow (I
    > check with 'date').
    >
    > Then, at the prompt I execute hwclock --localtime --hctosys again. I
    > check the 'date' and it is now correct.
    >
    > That means that hwclock is working properly (I always call it with
    > --localtime). So there is something else that messes things up...


    I'm not willing to "play with my own clock now after hearing of your
    woes.

    But when I issue:
    [pbrain]$ cat /etc/adjtime
    -248947.828125 1071042840 0.000000
    1071042840
    LOCAL

    I can see that the BIOS clock is maintaining LOCAL time and that the
    kernel used LOCAL time the last time it adjusted the BIOS clock. I
    don't think my BIOS clock has the ability to set/use UTC time as an
    option, I knew I was not particualrly interested in using UTC.

    [paulg@pbrain paulg]$ /sbin/hwclock --show (always shows local time)
    Wed 10 Dec 2003 10:58:51 PM CST -0.997798 seconds
    (the date is set back from a windows venture)

    while this is what I get with UTC:
    [pbrain]$ /sbin/hwclock --utc
    Wed 10 Dec 2003 04:59:50 PM CST -0.187991 seconds (which is correct
    -- 6 hrs west)

    (I made sure to follow this up with /sbin/hwclock --localtime to keep
    my system clock using LOCAL time. It is my understanding from the man
    pages that if I had not done so, my box would have used /etc/adjtime
    with the belief that I was now keeping time UTC and the last line in
    /etc/adjtime would have read UTC after next start up. This is about
    the only way to tell what kind of time you're keeping in the BIOS
    clock.)

    Normally, I use the KDE > Adjust Date & Time menu from the panel clock
    to set the time/date. I think I did manually set it back 1 hour this
    fall (can't remember for sure). On the Time Zone tab I've selected an
    appropriate TZ _and_ at the bottom the "System clock uses UTC" check
    box is cleared. At install time this same dialog appears and I
    believe I cleared the check box (ie., the default is checked?)

    I have no environment variables or files showing any TZ values. I do
    notice with some regularity that at shutdown, the kernel is in fact
    adjusting my BIOS clock from /etc/adjtime and is doing so with the
    understanding that I keep LOCAL time. I've not had time to dig
    through all the possible files used at startup and shutdown to see
    just what hwclock calls are being made. Sorry to say I will be busy
    till Christmas and not likely to get to it till afterwards.

    Man, I sure hope you can find out what's going on -- if it were me, it
    would bug me to death.

    LOL,
    prg
    email above disabled

  7. Re: Kernel Time and DST


    The details that you mention are exactly the same on my system, i.e. all
    the commands outputs on the prompt are correct. Beats me what's going on.
    I'll just change my time-zone to UTC to end my troubles.

    Ciao
    --
    Christos Dimitrakakis
    IDIAP (http://www.idiap.ch/~dimitrak/main.html)

  8. Re: Kernel Time and DST

    rdgentry1@cablelynx.com (P Gentry) writes:


    >
    >I'm not willing to "play with my own clock now after hearing of your
    >woes.
    >
    >But when I issue:
    >[pbrain]$ cat /etc/adjtime
    >-248947.828125 1071042840 0.000000
    >1071042840
    >LOCAL
    >
    >I can see that the BIOS clock is maintaining LOCAL time and that the
    >kernel used LOCAL time the last time it adjusted the BIOS clock. I
    >don't think my BIOS clock has the ability to set/use UTC time as an
    >option, I knew I was not particualrly interested in using UTC.


    Actually, the BIOS clock doesn't know squat about timezones. The
    problem with the BIOS clock is restricted to systems that dual-boot
    windows (which assumes that time values are relative to the local
    timezone) and unix/linux (which assumes that time values are relative
    to the GMT timezone - universal coordinated time (UTC)).

    So from the point of view of the BIOS, the time value is a date, hour
    and minute value. It is up to the operating system to interpret
    those values relative to a particular timezone.

    If you are not dual booting, i.e. if the machine is dedicated
    to linux or unix, you should always store the UTC value in the
    BIOS clock to avoid having to adjust it each time you boot
    and shutdown the system.

    To refresh your memory, time in linux/unix is maintained as the
    C datatype 'time_t' which is a 'long int' in linux. On Intel
    IA32 architectures, that value is a 32-bit signed integer which
    can represent time values from 1970 to 2038. The time is the
    number of seconds since January 1, 1970 GMT. Since the internal
    time_t value of the kernel is always maintained in UTC (only when
    times are displayed is your TZ environment variable examined to determine
    how the date should be presented), if you maintain the BIOS clock
    as local time, the system must adjust it by the correct amount when
    booting to ensure that the kernel time is still kept in UTC. Likewise
    when the system updates the BIOS clock it must readjust the kernel
    time_t value to the local TZ. This is an error prone problem and
    can cause the time to jump on reboot if everything doesn't work
    right (like an improper shutdown, for instance).

    To play with this a bit:

    bash$ TZ=PST8PDT date
    Fri Dec 19 10:18:04 PST 2003
    bash$ TZ=CST7CDT date
    Fri Dec 19 11:18:13 CST 2003

    Note that while the kernel clock TZ never changes (it is always
    UTC), the output of the date command does change based upon which
    timezone you request.

    Short answer: Store the BIOS time in UTC unless you are running
    VMware or using a dual boot setup with some flavor of Windows.

    scott

    >
    >[paulg@pbrain paulg]$ /sbin/hwclock --show (always shows local time)
    >Wed 10 Dec 2003 10:58:51 PM CST -0.997798 seconds
    >(the date is set back from a windows venture)
    >
    >while this is what I get with UTC:
    >[pbrain]$ /sbin/hwclock --utc
    >Wed 10 Dec 2003 04:59:50 PM CST -0.187991 seconds (which is correct
    >-- 6 hrs west)
    >
    >(I made sure to follow this up with /sbin/hwclock --localtime to keep
    >my system clock using LOCAL time. It is my understanding from the man
    >pages that if I had not done so, my box would have used /etc/adjtime
    >with the belief that I was now keeping time UTC and the last line in
    >/etc/adjtime would have read UTC after next start up. This is about
    >the only way to tell what kind of time you're keeping in the BIOS
    >clock.)
    >
    >Normally, I use the KDE > Adjust Date & Time menu from the panel clock
    >to set the time/date. I think I did manually set it back 1 hour this
    >fall (can't remember for sure). On the Time Zone tab I've selected an
    >appropriate TZ _and_ at the bottom the "System clock uses UTC" check
    >box is cleared. At install time this same dialog appears and I
    >believe I cleared the check box (ie., the default is checked?)
    >
    >I have no environment variables or files showing any TZ values. I do
    >notice with some regularity that at shutdown, the kernel is in fact
    >adjusting my BIOS clock from /etc/adjtime and is doing so with the
    >understanding that I keep LOCAL time. I've not had time to dig
    >through all the possible files used at startup and shutdown to see
    >just what hwclock calls are being made. Sorry to say I will be busy
    >till Christmas and not likely to get to it till afterwards.
    >
    >Man, I sure hope you can find out what's going on -- if it were me, it
    >would bug me to death.
    >
    >LOL,
    >prg
    >email above disabled


  9. Re: Kernel Time and DST

    scott@slp53.sl.home (Scott Lurndal) wrote in message news:<%iHEb.246$Qf5.151@newssvr25.news.prodigy.com>...
    > rdgentry1@cablelynx.com (P Gentry) writes:
    >
    >
    > >
    > >I'm not willing to "play with my own clock now after hearing of your
    > >woes.
    > >
    > >But when I issue:
    > >[pbrain]$ cat /etc/adjtime
    > >-248947.828125 1071042840 0.000000
    > >1071042840
    > >LOCAL
    > >
    > >I can see that the BIOS clock is maintaining LOCAL time and that the
    > >kernel used LOCAL time the last time it adjusted the BIOS clock. I
    > >don't think my BIOS clock has the ability to set/use UTC time as an
    > >option, I knew I was not particualrly interested in using UTC.

    >
    > Actually, the BIOS clock doesn't know squat about timezones. The
    > problem with the BIOS clock is restricted to systems that dual-boot
    > windows (which assumes that time values are relative to the local
    > timezone) and unix/linux (which assumes that time values are relative
    > to the GMT timezone - universal coordinated time (UTC)).
    >
    > So from the point of view of the BIOS, the time value is a date, hour
    > and minute value. It is up to the operating system to interpret
    > those values relative to a particular timezone.
    >
    > If you are not dual booting, i.e. if the machine is dedicated
    > to linux or unix, you should always store the UTC value in the
    > BIOS clock to avoid having to adjust it each time you boot
    > and shutdown the system.
    >
    > To refresh your memory, time in linux/unix is maintained as the
    > C datatype 'time_t' which is a 'long int' in linux. On Intel
    > IA32 architectures, that value is a 32-bit signed integer which
    > can represent time values from 1970 to 2038. The time is the
    > number of seconds since January 1, 1970 GMT. Since the internal
    > time_t value of the kernel is always maintained in UTC (only when
    > times are displayed is your TZ environment variable examined to determine
    > how the date should be presented), if you maintain the BIOS clock
    > as local time, the system must adjust it by the correct amount when
    > booting to ensure that the kernel time is still kept in UTC. Likewise
    > when the system updates the BIOS clock it must readjust the kernel
    > time_t value to the local TZ. This is an error prone problem and
    > can cause the time to jump on reboot if everything doesn't work
    > right (like an improper shutdown, for instance).
    >

    Thanks for the reminder. Been years since I fiddled with C's
    time/date routines and should have thought of this off the bat. DB's
    use their own formats (now _there's_ some ugly incompatibilities).
    But, yes, some BIOS's (not many -- maybe none now) would let you
    designate Local or UTC.

    Since calls to hwclock --hctosys are made at every boot (since the
    kernel has no way to keep time when not running) and time is adjusted
    for drift on shutdown with values in /etc/adjtime, I'm not convinced
    that maintaining time on my home PC is particularly error prone. And
    yes, being a home PC that others use and already contained Win98, I
    did imagine that selecting UTC on install several years ago would be a
    problem -- just a sneaky suspicion about the nature of Win rather than
    knowledge. Thanks.

    > To play with this a bit:
    >
    > bash$ TZ=PST8PDT date
    > Fri Dec 19 10:18:04 PST 2003
    > bash$ TZ=CST7CDT date
    > Fri Dec 19 11:18:13 CST 2003
    >
    > Note that while the kernel clock TZ never changes (it is always
    > UTC), the output of the date command does change based upon which
    > timezone you request.
    >
    > Short answer: Store the BIOS time in UTC unless you are running
    > VMware or using a dual boot setup with some flavor of Windows.
    >

    With stand alone servers this is an old habit from Novell days, with
    servers in different cities needing to keep somewhat in synch. Lucky
    in both ways, I guess.

    > scott
    >
    > >
    > >[paulg@pbrain paulg]$ /sbin/hwclock --show (always shows local time)
    > >Wed 10 Dec 2003 10:58:51 PM CST -0.997798 seconds
    > >(the date is set back from a windows venture)
    > >
    > >while this is what I get with UTC:
    > >[pbrain]$ /sbin/hwclock --utc
    > >Wed 10 Dec 2003 04:59:50 PM CST -0.187991 seconds (which is correct
    > >-- 6 hrs west)
    > >
    > >(I made sure to follow this up with /sbin/hwclock --localtime to keep
    > >my system clock using LOCAL time. It is my understanding from the man
    > >pages that if I had not done so, my box would have used /etc/adjtime
    > >with the belief that I was now keeping time UTC and the last line in
    > >/etc/adjtime would have read UTC after next start up. This is about
    > >the only way to tell what kind of time you're keeping in the BIOS
    > >clock.)
    > >
    > >Normally, I use the KDE > Adjust Date & Time menu from the panel clock
    > >to set the time/date. I think I did manually set it back 1 hour this
    > >fall (can't remember for sure). On the Time Zone tab I've selected an
    > >appropriate TZ _and_ at the bottom the "System clock uses UTC" check
    > >box is cleared. At install time this same dialog appears and I
    > >believe I cleared the check box (ie., the default is checked?)
    > >
    > >I have no environment variables or files showing any TZ values. I do
    > >notice with some regularity that at shutdown, the kernel is in fact
    > >adjusting my BIOS clock from /etc/adjtime and is doing so with the
    > >understanding that I keep LOCAL time. I've not had time to dig
    > >through all the possible files used at startup and shutdown to see
    > >just what hwclock calls are being made. Sorry to say I will be busy
    > >till Christmas and not likely to get to it till afterwards.
    > >
    > >Man, I sure hope you can find out what's going on -- if it were me, it
    > >would bug me to death.
    > >
    > >LOL,
    > >prg
    > >email above disabled


    Thanks for the clarifications and reminders. Is it correct to assume,
    as I did, that OP has BIOS clock set to local while the kernel is
    assuming it is set to UTC (or vice versa)? The man pages say "you
    askin' for trouble, dude" if that's the case.

    Thanks again,
    prg
    email above disabled

  10. Re: Kernel Time and DST

    Christos Dimitrakakis wrote:
    > I had RH9 installed this summer on my system. Ever since the change from
    > DST to normal time there had been a problem with the kernel time. This is
    > what happens.
    >


    You should have set your clock to run in GMT, if the hardware clock is
    on GMT everything works without fiddling. You can bull your way through
    the startup scripts after that to fix it, or diddle with sysconf files.

    --
    bill davidsen
    CTO TMR Associates, Inc
    Doing interesting things with small computers since 1979


+ Reply to Thread