Clock did not adjust for daylight saving - Suse

This is a discussion on Clock did not adjust for daylight saving - Suse ; Pat wrote: > For some reason the clock on my openSUSE 10.2 system did not adjust for > daylight savings. Does the clock not periodically synchronize (like > once or twice a day) with a time server by default. If ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 23

Thread: Clock did not adjust for daylight saving

  1. Re: Clock did not adjust for daylight saving

    Pat wrote:
    > For some reason the clock on my openSUSE 10.2 system did not adjust for
    > daylight savings. Does the clock not periodically synchronize (like
    > once or twice a day) with a time server by default. If not, is there a
    > way to set this up?


    Do you parallel boot a Windows installation? If yes it's more likely that
    combination screwed it up.

    Also check whether the hw clock is set to utc or local time.
    Furthermore, keep in mind that a dst change is not a change in time, but
    displaying the same utc time in a different time zone.

    And while you set up the ntpd, learn that it's not for periodically running
    ntpdate and setting the clock, but for doing that AND adjusting the
    local speed of the kernel clock to the correct values.

    kind regards,
    Andreas

  2. Clock did not adjust for daylight saving

    For some reason the clock on my openSUSE 10.2 system did not adjust for
    daylight savings. Does the clock not periodically synchronize (like
    once or twice a day) with a time server by default. If not, is there a
    way to set this up?

    Thanks, -Pat

  3. Re: Clock did not adjust for daylight saving

    Hi,

    Pat wrote:
    > Andreas wrote:
    >> Pat wrote:
    >>> For some reason the clock on my openSUSE 10.2 system did not adjust for
    >>> daylight savings. Does the clock not periodically synchronize (like
    >>> once or twice a day) with a time server by default. If not, is there a
    >>> way to set this up?

    >>
    >> Do you parallel boot a Windows installation? If yes it's more likely that
    >> combination screwed it up.
    >>
    >> Also check whether the hw clock is set to utc or local time.
    >> Furthermore, keep in mind that a dst change is not a change in time, but
    >> displaying the same utc time in a different time zone.
    >>
    >> And while you set up the ntpd, learn that it's not for periodically running
    >> ntpdate and setting the clock, but for doing that AND adjusting the
    >> local speed of the kernel clock to the correct values.
    >>
    >> kind regards,
    >> Andreas

    >
    > Thanks Andreas.
    >
    > Yes, I do boot into Windows occasionally (both dual boot and VMware).
    > So perhaps that is what caused the problem.
    >
    > I checked, and the clock is set to local. Should it be set to utc?


    If you dual boot, you should set it to local, because this is how windows
    does it and it can't handle a utc hardware clock. But this means that
    this clock changes time zones twice, hence the difference in your machine.
    (Think of mom and dad both setting the kitchen clock back one hour,
    instead of the kitchen clock running at utc with a time zone calendar
    next to it)

    kind regards,
    Andreas

  4. Re: Clock did not adjust for daylight saving

    Pat wrote:
    > Thanks Andreas.
    >
    > Yes, I do boot into Windows occasionally (both dual boot and VMware).
    > So perhaps that is what caused the problem.
    >
    > I checked, and the clock is set to local. Should it be set to utc?


    A normal OS works with UTC. However M$ does not, so you will need to use
    local time when using M$. Normaly this is not a real problem and should
    solve the issue.

    I have seen a security update for wintertime settings, although I do not
    know for what part of the world that was, so if you have missed that and
    did not do an update, it might be the cause.

    Look in YaST to see if all settings are correct and if you have selected
    the correct timezone.

    houghi
    --
    At the source of every error which is blamed on the computer you will
    find at least two human errors, including the error of blaming it on
    the computer.

  5. Re: Clock did not adjust for daylight saving

    On Mon, 05 Nov 2007 08:59:23 -0500, Pat wrote:

    > For some reason the clock on my openSUSE 10.2 system did not adjust for
    > daylight savings. Does the clock not periodically synchronize (like
    > once or twice a day) with a time server by default. If not, is there a
    > way to set this up?
    >
    > Thanks, -Pat


    As I understand it, time servers always broadcast GMT - think about it,
    how would it know what time zone you were in; and different politicaly
    entities have never agreed on when to start and end DST.


  6. Re: Clock did not adjust for daylight saving

    Andreas wrote:
    > Pat wrote:
    >> For some reason the clock on my openSUSE 10.2 system did not adjust for
    >> daylight savings. Does the clock not periodically synchronize (like
    >> once or twice a day) with a time server by default. If not, is there a
    >> way to set this up?

    >
    > Do you parallel boot a Windows installation? If yes it's more likely that
    > combination screwed it up.
    >
    > Also check whether the hw clock is set to utc or local time.
    > Furthermore, keep in mind that a dst change is not a change in time, but
    > displaying the same utc time in a different time zone.
    >
    > And while you set up the ntpd, learn that it's not for periodically running
    > ntpdate and setting the clock, but for doing that AND adjusting the
    > local speed of the kernel clock to the correct values.
    >
    > kind regards,
    > Andreas


    Thanks Andreas.

    Yes, I do boot into Windows occasionally (both dual boot and VMware).
    So perhaps that is what caused the problem.

    I checked, and the clock is set to local. Should it be set to utc?


  7. Re: Clock did not adjust for daylight saving

    On Mon, 2007-11-05 at 08:59 -0500, Pat wrote:
    > For some reason the clock on my openSUSE 10.2 system did not adjust for
    > daylight savings. Does the clock not periodically synchronize (like
    > once or twice a day) with a time server by default. If not, is there a
    > way to set this up?
    >
    > Thanks, -Pat


    Our fully patched SLES10 boxes didn't adjust either... we're
    researching.



  8. Re: Clock did not adjust for daylight saving

    Andreas writes:

    >Pat wrote:
    >> For some reason the clock on my openSUSE 10.2 system did not adjust for
    >> daylight savings. Does the clock not periodically synchronize (like
    >> once or twice a day) with a time server by default. If not, is there a
    >> way to set this up?


    The clock does not periodically synchronize unless you set it up to do so.
    That is what programs like ntp, openntp, chrony are designed to do, but you
    must install them and set them up .

    Furthermore you much make sure that you installed the latest (2 year old by
    now) version of tzdata (the timezone package on your system. Not sure what
    SUSE calls it). Finally you must run your harware clock on UTC, not on
    localtime ( which you may be doing as below. Windows demands it be on local
    time and tries badly to adjust that time at DST but usually makes a hash of
    it. BUt this means that Linux and Windows are incompatible. Thus if you
    tell Linux the hardware clock is on localtime, it will leave all DST
    adjustment of the hardware clock up to you.)



    >Do you parallel boot a Windows installation? If yes it's more likely that
    >combination screwed it up.


    >Also check whether the hw clock is set to utc or local time.
    >Furthermore, keep in mind that a dst change is not a change in time, but
    >displaying the same utc time in a different time zone.


    To amplify, on Linux, the system time is ALWAYS UTC, and the /etc/localtime
    file tells Linux how to translate from UTC to local time, including all DST
    adjustments. On boot up, Linux gets the time from the harware clock. If the
    harware clock is on UTC everything is peachy. If not, Linux has no idea if
    you or windows changed the time on that clock at DST and assumes you did.
    But that is up to you.



    >And while you set up the ntpd, learn that it's not for periodically running
    >ntpdate and setting the clock, but for doing that AND adjusting the
    >local speed of the kernel clock to the correct values.


    Periodicaly running ntpdate is one possible way of using ntp, but not the
    best usually. (If you have only sporadic connection to the net, that may be
    the best way).



    >kind regards,
    >Andreas


  9. Re: Clock did not adjust for daylight saving

    Andreas writes:

    >Hi,


    >Pat wrote:
    >> Andreas wrote:
    >>> Pat wrote:
    >>>> For some reason the clock on my openSUSE 10.2 system did not adjust for
    >>>> daylight savings. Does the clock not periodically synchronize (like
    >>>> once or twice a day) with a time server by default. If not, is there a
    >>>> way to set this up?
    >>>
    >>> Do you parallel boot a Windows installation? If yes it's more likely that
    >>> combination screwed it up.
    >>>
    >>> Also check whether the hw clock is set to utc or local time.
    >>> Furthermore, keep in mind that a dst change is not a change in time, but
    >>> displaying the same utc time in a different time zone.
    >>>
    >>> And while you set up the ntpd, learn that it's not for periodically running
    >>> ntpdate and setting the clock, but for doing that AND adjusting the
    >>> local speed of the kernel clock to the correct values.
    >>>
    >>> kind regards,
    >>> Andreas

    >>
    >> Thanks Andreas.
    >>
    >> Yes, I do boot into Windows occasionally (both dual boot and VMware).
    >> So perhaps that is what caused the problem.
    >>
    >> I checked, and the clock is set to local. Should it be set to utc?


    >If you dual boot, you should set it to local, because this is how windows
    >does it and it can't handle a utc hardware clock. But this means that
    >this clock changes time zones twice, hence the difference in your machine.
    >(Think of mom and dad both setting the kitchen clock back one hour,
    >instead of the kitchen clock running at utc with a time zone calendar
    >next to it)


    Linux NEVER resets the hardware clock unless you tell it to. (Some distros
    do tell the system to reset the hardware clock on shutdown). It assumes
    that that the hardware clock is correct. If you set it to local, it assumes
    that you will have taken care of any DST adjustments to it. If you do not
    intend to do that, set it to utc.


    >kind regards,
    >Andreas


  10. Re: Clock did not adjust for daylight saving

    houghi wrote:

    > Pat wrote:
    >> Thanks Andreas.
    >>
    >> Yes, I do boot into Windows occasionally (both dual boot and VMware).
    >> So perhaps that is what caused the problem.
    >>
    >> I checked, and the clock is set to local. Should it be set to utc?

    >
    > A normal OS works with UTC. However M$ does not, so you will need to use
    > local time when using M$. Normaly this is not a real problem and should
    > solve the issue.
    >
    > I have seen a security update for wintertime settings, although I do not
    > know for what part of the world that was, so if you have missed that and
    > did not do an update, it might be the cause.
    >
    > Look in YaST to see if all settings are correct and if you have selected
    > the correct timezone.
    >
    > houghi


    I have several dual-boot systems and what I do with them is to set the
    hardware clock to local time in SuSE/YaST and set up Windows to adjust it
    using a time server and automatic summer time adjustment. When the clocks
    change or if the PC's clock gets too far out of line, I boot into Windows
    and let it sort it out. Seems to work OK though it's not ideal of course
    (ideal is no Windows). If anyone knows a better dual-boot approach, please
    let us in on it.

    From what I've observed, VMWare is a different matter. I think what it does
    is to emulate the real time clock chip in the guest system by storing a
    time difference and adding that to the time on the host system (Windows or
    Linux). When the guest OS (running on the virtual machine) tries to set the
    real time clock, VMWare doesn't do this but only recalculates the stored
    time difference. Running Windows as a guest system under VMWare won't
    affect the time on the host system but the time on the guest system may get
    adjusted twice if you aren't careful.

    Regarding updates for winter time settings - the Americans have changed the
    rules this year which will have triggered updates for both Windows and
    Linux but this will only affect PCs set to North American time zones. We
    all get them though whether we need them or not (I'm not complaining).

    --
    ---Steve Hayes, South Wales, UK---
    Please remove colours from address

  11. Re: Clock did not adjust for daylight saving

    On Mon, 05 Nov 2007, in the Usenet newsgroup alt.os.linux.suse, in article
    <_cOdneGoztu5jrLanZ2dnUVZ_oGjnZ2d@insightbb.com>, Pat wrote:

    >For some reason the clock on my openSUSE 10.2 system did not adjust for
    >daylight savings.


    Let's start by asking what timezone you are set for, and how your
    system is set (HW clock on localtime? Windoze?) Assuming the USA
    and Eastern time zone, what do you see when you do

    [pathfinder ~]$ /usr/sbin/zdump -v US/Eastern | grep 2007
    US/Eastern Sun Mar 11 06:59:59 2007 GMT = Sun Mar 11 01:59:59 2007 EST isdst=0
    US/Eastern Sun Mar 11 07:00:00 2007 GMT = Sun Mar 11 03:00:00 2007 EDT isdst=1
    US/Eastern Sun Nov 4 05:59:59 2007 GMT = Sun Nov 4 01:59:59 2007 EDT isdst=1
    US/Eastern Sun Nov 4 06:00:00 2007 GMT = Sun Nov 4 01:00:00 2007 EST isdst=0
    [pathfinder ~]$ /sbin/hwclock --show ; date ; date -u
    Mon Nov 6 00:11:38 2007 -0.101390 seconds
    Mon Nov 5 17:11:38 MST 2007
    Tue Nov 6 00:11:38 UTC 2007
    [pathfinder ~]$

    Here, my hardware clock is set to UTC, and my local timezone is 5 hours
    behind UTC.

    What 'zone files' are you using? From a command line as above, run the
    command 'rpm -qa | grep tzdata' and you want to see it reporting a
    file later than 'tzdata2005m' (year 2005, m=13th revision). openSUSE 10.2
    dates from the end of 2006, so it _should_ have the "current" file unless
    you are in Indiana where the politicians were continuing to screw with the
    rules as late as tzdata2007g.

    >Does the clock not periodically synchronize (like once or twice a day)
    >with a time server by default.


    Not unless you set it up separately - but that really doesn't matter
    because Internet time servers speak only UTC and haven't a clue about
    ANY timezone, much less when DST may or may not change things. I'm near
    Phoenix, Arizona, and we don't observe DST in this state except in the
    Navajo Nation (Northeast part of the state) which does, except within
    the Hopi Nation (within the Navaho Nation boundries, within Arizona)
    which also ignores DST, except in the town of Jeddito (within the Hopi
    Nation boundries, within the Navaho Nation boundries, within Arizona)
    which does use DST. No, I'm not making this up.

    >If not, is there a way to set this up?


    NTP isn't going to solve the DST issue, as it only knows UTC.

    Old guy

  12. Re: Clock did not adjust for daylight saving

    Steve Hayes writes:

    >houghi wrote:


    >> Pat wrote:
    >>> Thanks Andreas.
    >>>
    >>> Yes, I do boot into Windows occasionally (both dual boot and VMware).
    >>> So perhaps that is what caused the problem.
    >>>
    >>> I checked, and the clock is set to local. Should it be set to utc?

    >>
    >> A normal OS works with UTC. However M$ does not, so you will need to use
    >> local time when using M$. Normaly this is not a real problem and should
    >> solve the issue.
    >>
    >> I have seen a security update for wintertime settings, although I do not
    >> know for what part of the world that was, so if you have missed that and
    >> did not do an update, it might be the cause.
    >>
    >> Look in YaST to see if all settings are correct and if you have selected
    >> the correct timezone.
    >>
    >> houghi


    >I have several dual-boot systems and what I do with them is to set the
    >hardware clock to local time in SuSE/YaST and set up Windows to adjust it
    >using a time server and automatic summer time adjustment. When the clocks
    >change or if the PC's clock gets too far out of line, I boot into Windows
    >and let it sort it out. Seems to work OK though it's not ideal of course
    >(ideal is no Windows). If anyone knows a better dual-boot approach, please
    >let us in on it.


    Well, that is one way. If I occasionally had to use windows, I would simply
    leave the RTC on UTC, and grin an bear it when I used windows.

    Ie, the windows time would be way out ( 8 hours for me) but so what since I
    use it rarely.


    >From what I've observed, VMWare is a different matter. I think what it does
    >is to emulate the real time clock chip in the guest system by storing a
    >time difference and adding that to the time on the host system (Windows or
    >Linux). When the guest OS (running on the virtual machine) tries to set the
    >real time clock, VMWare doesn't do this but only recalculates the stored
    >time difference. Running Windows as a guest system under VMWare won't
    >affect the time on the host system but the time on the guest system may get
    >adjusted twice if you aren't careful.


    >Regarding updates for winter time settings - the Americans have changed the
    >rules this year which will have triggered updates for both Windows and
    >Linux but this will only affect PCs set to North American time zones. We
    >all get them though whether we need them or not (I'm not complaining).


    Many places in the world have changed. Australia has changed its rules
    about 5 times in the past 5 years, including I believe at least once for a
    horse race (Melbourne cup?). Other areas of the world have also
    changed. (eg Kuwait,Turkey,... ) The tzdata file goes through about 10 changes per year. Only a few
    over the past two years have been North America.

    Windows of course only knows about North America, and that badly. Linux knows about the
    world.


    >--
    >---Steve Hayes, South Wales, UK---
    >Please remove colours from address


  13. Re: Clock did not adjust for daylight saving

    ibuprofin@painkiller.example.tld (Moe Trin) writes:

    >On Mon, 05 Nov 2007, in the Usenet newsgroup alt.os.linux.suse, in article
    ><_cOdneGoztu5jrLanZ2dnUVZ_oGjnZ2d@insightbb.com>, Pat wrote:


    >>For some reason the clock on my openSUSE 10.2 system did not adjust for
    >>daylight savings.


    >Let's start by asking what timezone you are set for, and how your
    >system is set (HW clock on localtime? Windoze?) Assuming the USA
    >and Eastern time zone, what do you see when you do


    >[pathfinder ~]$ /usr/sbin/zdump -v US/Eastern | grep 2007
    >US/Eastern Sun Mar 11 06:59:59 2007 GMT = Sun Mar 11 01:59:59 2007 EST isdst=0
    >US/Eastern Sun Mar 11 07:00:00 2007 GMT = Sun Mar 11 03:00:00 2007 EDT isdst=1
    >US/Eastern Sun Nov 4 05:59:59 2007 GMT = Sun Nov 4 01:59:59 2007 EDT isdst=1
    >US/Eastern Sun Nov 4 06:00:00 2007 GMT = Sun Nov 4 01:00:00 2007 EST isdst=0
    >[pathfinder ~]$ /sbin/hwclock --show ; date ; date -u
    >Mon Nov 6 00:11:38 2007 -0.101390 seconds
    >Mon Nov 5 17:11:38 MST 2007
    >Tue Nov 6 00:11:38 UTC 2007
    >[pathfinder ~]$


    >Here, my hardware clock is set to UTC, and my local timezone is 5 hours
    >behind UTC.


    >What 'zone files' are you using? From a command line as above, run the
    >command 'rpm -qa | grep tzdata' and you want to see it reporting a
    >file later than 'tzdata2005m' (year 2005, m=13th revision). openSUSE 10.2
    >dates from the end of 2006, so it _should_ have the "current" file unless
    >you are in Indiana where the politicians were continuing to screw with the
    >rules as late as tzdata2007g.


    >>Does the clock not periodically synchronize (like once or twice a day)
    >>with a time server by default.


    >Not unless you set it up separately - but that really doesn't matter
    >because Internet time servers speak only UTC and haven't a clue about
    >ANY timezone, much less when DST may or may not change things. I'm near
    >Phoenix, Arizona, and we don't observe DST in this state except in the
    >Navajo Nation (Northeast part of the state) which does, except within
    >the Hopi Nation (within the Navaho Nation boundries, within Arizona)
    >which also ignores DST, except in the town of Jeddito (within the Hopi
    >Nation boundries, within the Navaho Nation boundries, within Arizona)
    >which does use DST. No, I'm not making this up.


    >>If not, is there a way to set this up?


    >NTP isn't going to solve the DST issue, as it only knows UTC.



    His problem is that his hardware clock is not properly setting his system
    time at boot up I suspect. Linux also knows only UTC when it is running.
    The /etc/localtime file is only used to interpret utc for the user when
    displaying times to the user. Linux is UTC.

    So I suspect that his timezone is set up fine. It is his hardware clock
    that is the problem.


    > Old guy


  14. Re: Clock did not adjust for daylight saving

    Moe Trin wrote:
    > On Mon, 05 Nov 2007, in the Usenet newsgroup alt.os.linux.suse, in article
    > <_cOdneGoztu5jrLanZ2dnUVZ_oGjnZ2d@insightbb.com>, Pat wrote:
    >
    >> For some reason the clock on my openSUSE 10.2 system did not adjust for
    >> daylight savings.

    >
    > Let's start by asking what timezone you are set for, and how your
    > system is set (HW clock on localtime? Windoze?) Assuming the USA
    > and Eastern time zone, what do you see when you do
    >
    > [pathfinder ~]$ /usr/sbin/zdump -v US/Eastern | grep 2007
    > US/Eastern Sun Mar 11 06:59:59 2007 GMT = Sun Mar 11 01:59:59 2007 EST isdst=0
    > US/Eastern Sun Mar 11 07:00:00 2007 GMT = Sun Mar 11 03:00:00 2007 EDT isdst=1
    > US/Eastern Sun Nov 4 05:59:59 2007 GMT = Sun Nov 4 01:59:59 2007 EDT isdst=1
    > US/Eastern Sun Nov 4 06:00:00 2007 GMT = Sun Nov 4 01:00:00 2007 EST isdst=0
    > [pathfinder ~]$ /sbin/hwclock --show ; date ; date -u
    > Mon Nov 6 00:11:38 2007 -0.101390 seconds
    > Mon Nov 5 17:11:38 MST 2007
    > Tue Nov 6 00:11:38 UTC 2007
    > [pathfinder ~]$
    >
    > Here, my hardware clock is set to UTC, and my local timezone is 5 hours
    > behind UTC.
    >
    > What 'zone files' are you using? From a command line as above, run the
    > command 'rpm -qa | grep tzdata' and you want to see it reporting a
    > file later than 'tzdata2005m' (year 2005, m=13th revision). openSUSE 10.2
    > dates from the end of 2006, so it _should_ have the "current" file unless
    > you are in Indiana where the politicians were continuing to screw with the
    > rules as late as tzdata2007g.
    >
    >> Does the clock not periodically synchronize (like once or twice a day)
    >> with a time server by default.

    >
    > Not unless you set it up separately - but that really doesn't matter
    > because Internet time servers speak only UTC and haven't a clue about
    > ANY timezone, much less when DST may or may not change things. I'm near
    > Phoenix, Arizona, and we don't observe DST in this state except in the
    > Navajo Nation (Northeast part of the state) which does, except within
    > the Hopi Nation (within the Navaho Nation boundries, within Arizona)
    > which also ignores DST, except in the town of Jeddito (within the Hopi
    > Nation boundries, within the Navaho Nation boundries, within Arizona)
    > which does use DST. No, I'm not making this up.
    >
    >> If not, is there a way to set this up?

    >
    > NTP isn't going to solve the DST issue, as it only knows UTC.
    >
    > Old guy



    Thanks for all the replies and suggestions. It's was interesting to
    read about the various issues and nuances involved with this.

    I think I understand now why my clock failed to adjust for DST. My use
    of Windows XP is infrequent and almost entirely though VMware Server.
    So the "local" time I was using had no way of updating. I've now
    switched it to UTC, and everything appears correct - it's showing 7:17
    am, as it should. It will be interesting to see what happens in the
    spring though, when the time switches back again.

    Thanks again for the help. This is a great user group. -Pat


  15. Re: Clock did not adjust for daylight saving

    Unruh wrote:

    > Steve Hayes writes:
    >
    >>houghi wrote:

    >
    >>> Pat wrote:
    >>>> Thanks Andreas.
    >>>>
    >>>> Yes, I do boot into Windows occasionally (both dual boot and VMware).
    >>>> So perhaps that is what caused the problem.
    >>>>
    >>>> I checked, and the clock is set to local. Should it be set to utc?
    >>>
    >>> A normal OS works with UTC. However M$ does not, so you will need to use
    >>> local time when using M$. Normaly this is not a real problem and should
    >>> solve the issue.
    >>>
    >>> I have seen a security update for wintertime settings, although I do not
    >>> know for what part of the world that was, so if you have missed that and
    >>> did not do an update, it might be the cause.
    >>>
    >>> Look in YaST to see if all settings are correct and if you have selected
    >>> the correct timezone.
    >>>
    >>> houghi

    >
    >>I have several dual-boot systems and what I do with them is to set the
    >>hardware clock to local time in SuSE/YaST and set up Windows to adjust it
    >>using a time server and automatic summer time adjustment. When the clocks
    >>change or if the PC's clock gets too far out of line, I boot into Windows
    >>and let it sort it out. Seems to work OK though it's not ideal of course
    >>(ideal is no Windows). If anyone knows a better dual-boot approach, please
    >>let us in on it.

    >
    > Well, that is one way. If I occasionally had to use windows, I would
    > simply leave the RTC on UTC, and grin an bear it when I used windows.
    >
    > Ie, the windows time would be way out ( 8 hours for me) but so what since
    > I use it rarely.
    >
    >
    >>From what I've observed, VMWare is a different matter. I think what it
    >>does is to emulate the real time clock chip in the guest system by storing
    >>a time difference and adding that to the time on the host system (Windows
    >>or Linux). When the guest OS (running on the virtual machine) tries to set
    >>the real time clock, VMWare doesn't do this but only recalculates the
    >>stored time difference. Running Windows as a guest system under VMWare
    >>won't affect the time on the host system but the time on the guest system
    >>may get adjusted twice if you aren't careful.

    >
    >>Regarding updates for winter time settings - the Americans have changed
    >>the rules this year which will have triggered updates for both Windows and
    >>Linux but this will only affect PCs set to North American time zones. We
    >>all get them though whether we need them or not (I'm not complaining).

    >
    > Many places in the world have changed. Australia has changed its rules
    > about 5 times in the past 5 years, including I believe at least once for a
    > horse race (Melbourne cup?). Other areas of the world have also
    > changed. (eg Kuwait,Turkey,... ) The tzdata file goes through about 10
    > changes per year. Only a few over the past two years have been North
    > America.
    >
    > Windows of course only knows about North America, and that badly.


    Yup. It changed time in Ohio one week early. OpenSuse 10.3 naturally got
    it right.

    > Linux
    > knows about the world.
    >
    >
    >>--
    >>---Steve Hayes, South Wales, UK---
    >>Please remove colours from address


    --
    Later,
    Darrell Stec darstec@neo.rr.com

    Webpage Sorcery
    http://webpagesorcery.com
    We Put the Magic in Your Webpages

  16. Re: Clock did not adjust for daylight saving

    On 2007-11-05 17:13, Pat wrote:
    > Andreas wrote:
    >> Pat wrote:
    >>> For some reason the clock on my openSUSE 10.2 system did not adjust for
    >>> daylight savings. Does the clock not periodically synchronize (like
    >>> once or twice a day) with a time server by default. If not, is there a
    >>> way to set this up?

    >> Do you parallel boot a Windows installation? If yes it's more likely that
    >> combination screwed it up.
    >>
    >> Also check whether the hw clock is set to utc or local time.
    >> Furthermore, keep in mind that a dst change is not a change in time, but
    >> displaying the same utc time in a different time zone.
    >>
    >> And while you set up the ntpd, learn that it's not for periodically running
    >> ntpdate and setting the clock, but for doing that AND adjusting the
    >> local speed of the kernel clock to the correct values.
    >>
    >> kind regards,
    >> Andreas

    >
    > Thanks Andreas.
    >
    > Yes, I do boot into Windows occasionally (both dual boot and VMware).
    > So perhaps that is what caused the problem.
    >
    > I checked, and the clock is set to local. Should it be set to utc?
    >


    There is your problem, Windows as usual, since this is a single user
    OS that change the hardware clock to the new local time, ignoring the fact
    that we since long has Internet and the user can be in another timezone.

    Multiuser systems never change the clock, but display the time as the user
    will have it.

    As folks say, one way is to tell linux that your clock is local time, but
    that will also give you some problems, since Linux can't know if windows
    adjusted it or not, but must compensate for it.

    I suggest you let Linux have the clock in UTC, and use NTP for both
    Linux and Windows, Linux has it default, just set it up in YaST using a public
    pool near you, and install NTP for windows.
    http://www.meinberg.de/english/sw/ntp.htm
    Then your clock will in worst case go one hour off when you boot, but will be
    correct before you login.
    And you must have the correct timezone, not any GMT+-offset.

    When Windows is removed, it will work as expected.

    /bb

  17. Re: Clock did not adjust for daylight saving

    Pat writes:

    >Moe Trin wrote:
    >> On Mon, 05 Nov 2007, in the Usenet newsgroup alt.os.linux.suse, in article
    >> <_cOdneGoztu5jrLanZ2dnUVZ_oGjnZ2d@insightbb.com>, Pat wrote:
    >>
    >>> For some reason the clock on my openSUSE 10.2 system did not adjust for
    >>> daylight savings.

    >>
    >> Let's start by asking what timezone you are set for, and how your
    >> system is set (HW clock on localtime? Windoze?) Assuming the USA
    >> and Eastern time zone, what do you see when you do
    >>
    >> [pathfinder ~]$ /usr/sbin/zdump -v US/Eastern | grep 2007
    >> US/Eastern Sun Mar 11 06:59:59 2007 GMT = Sun Mar 11 01:59:59 2007 EST isdst=0
    >> US/Eastern Sun Mar 11 07:00:00 2007 GMT = Sun Mar 11 03:00:00 2007 EDT isdst=1
    >> US/Eastern Sun Nov 4 05:59:59 2007 GMT = Sun Nov 4 01:59:59 2007 EDT isdst=1
    >> US/Eastern Sun Nov 4 06:00:00 2007 GMT = Sun Nov 4 01:00:00 2007 EST isdst=0
    >> [pathfinder ~]$ /sbin/hwclock --show ; date ; date -u
    >> Mon Nov 6 00:11:38 2007 -0.101390 seconds
    >> Mon Nov 5 17:11:38 MST 2007
    >> Tue Nov 6 00:11:38 UTC 2007
    >> [pathfinder ~]$
    >>
    >> Here, my hardware clock is set to UTC, and my local timezone is 5 hours
    >> behind UTC.
    >>
    >> What 'zone files' are you using? From a command line as above, run the
    >> command 'rpm -qa | grep tzdata' and you want to see it reporting a
    >> file later than 'tzdata2005m' (year 2005, m=13th revision). openSUSE 10.2
    >> dates from the end of 2006, so it _should_ have the "current" file unless
    >> you are in Indiana where the politicians were continuing to screw with the
    >> rules as late as tzdata2007g.
    >>
    >>> Does the clock not periodically synchronize (like once or twice a day)
    >>> with a time server by default.

    >>
    >> Not unless you set it up separately - but that really doesn't matter
    >> because Internet time servers speak only UTC and haven't a clue about
    >> ANY timezone, much less when DST may or may not change things. I'm near
    >> Phoenix, Arizona, and we don't observe DST in this state except in the
    >> Navajo Nation (Northeast part of the state) which does, except within
    >> the Hopi Nation (within the Navaho Nation boundries, within Arizona)
    >> which also ignores DST, except in the town of Jeddito (within the Hopi
    >> Nation boundries, within the Navaho Nation boundries, within Arizona)
    >> which does use DST. No, I'm not making this up.
    >>
    >>> If not, is there a way to set this up?

    >>
    >> NTP isn't going to solve the DST issue, as it only knows UTC.
    >>
    >> Old guy



    >Thanks for all the replies and suggestions. It's was interesting to
    >read about the various issues and nuances involved with this.


    >I think I understand now why my clock failed to adjust for DST. My use
    >of Windows XP is infrequent and almost entirely though VMware Server.
    >So the "local" time I was using had no way of updating. I've now
    >switched it to UTC, and everything appears correct - it's showing 7:17
    >am, as it should. It will be interesting to see what happens in the
    >spring though, when the time switches back again.


    As one who has used Linux for years, there will be absolutely nothing to
    see. At 2AM in March, you will find that all displayed times have gained an
    hour. And if the legislatures around the world decide to change things
    again, within a week there will be a new tzdata file which incorporates
    those changes and within a month all distros will have distrubuted it.



    >Thanks again for the help. This is a great user group. -Pat



  18. Re: Clock did not adjust for daylight saving

    On Tue, 06 Nov 2007, in the Usenet newsgroup alt.os.linux.suse, in article
    , Pat wrote:

    >Thanks for all the replies and suggestions. It's was interesting to
    >read about the various issues and nuances involved with this.


    -rw-r--r-- 1 8800 0 162977 Nov 1 14:16 tzdata2007i.tar.gz

    That's the source of the data files (on elsie.nci.nih.gov) and opening
    that tarball gives 19 text files needed for the 'zic' compiler to
    create the actual timezone files your system uses. There are no less
    than 393 timezones in those files - although clocks around the world
    may be displaying 35 different "local" times (there are 11 non-hour
    increment zones, such as India [+05:30], central Oz [+09:30], and
    Newfoundland [-03:30]). Expecting the 244 nations around the world to
    agree when to change the clocks (if at all) is hopeless.

    >I think I understand now why my clock failed to adjust for DST. My use
    >of Windows XP is infrequent and almost entirely though VMware Server.
    >So the "local" time I was using had no way of updating.


    Bingo! Telling Linux that the BIOS clock is set to "localtime" means
    that some other entity is making sure the clock is set correctly. This
    could be windoze, or it could be you getting into the BIOS setup twice
    a year to correct things. Most operating systems use two clocks - a
    software clock which is what the UNIX 'date' command and most eye-candy
    clocks on GUI desktops show, and the hardware clock in the BIOS. Most
    O/S only look at the hardware clock at boot time using it to set the
    starting time of the software clock. Most O/S have commands that can
    be used to _set_ the hardware clock, but this is a user preference
    that most Linux distributions don't use by default (windoze can be
    set to correct the BIOS clock for DST shifts - which may or may not
    be desirable).

    >I've now switched it to UTC, and everything appears correct - it's
    >showing 7:17 am, as it should. It will be interesting to see what
    >happens in the spring though, when the time switches back again.


    If you can tell windoze that the BIOS clock is set to UTC _and_ if
    it knows the "correct" schedule and offset, things should be fine.
    As far as Linux is concerned, if the system is set to UTC and is
    aware of the correct timezone names - you're home free until the
    congress-critters get another hair out of shape and decide to mess
    with the clock once again. As most of what they do is to give the
    illusion of doing "something", anything is possible.

    Old guy

  19. Re: Clock did not adjust for daylight saving

    On Tue, 06 Nov 2007, in the Usenet newsgroup alt.os.linux.suse, in article
    , Unruh wrote:

    >And if the legislatures around the world decide to change things
    >again, within a week there will be a new tzdata file which
    >incorporates those changes and within a month all distros will have
    >distrubuted it.


    That's a heck of a lot of confidence in the various distribution
    maintainers. More that I have in them.

    -rw-r--r-- 1 8800 0 157506 Jan 8 17:28 tzdata2007a.tar.gz
    -rw-r--r-- 1 8800 0 157432 Feb 12 14:34 tzdata2007b.tar.gz
    -rw-r--r-- 1 8800 0 158198 Feb 26 14:09 tzdata2007c.tar.gz
    -rw-r--r-- 1 8800 0 159373 Mar 20 12:48 tzdata2007d.tar.gz
    -rw-r--r-- 1 8800 0 159753 Apr 2 14:11 tzdata2007e.tar.gz
    -rw-r--r-- 1 8800 0 160513 May 7 14:46 tzdata2007f.tar.gz
    -rw-r--r-- 1 8800 0 161080 Aug 20 14:48 tzdata2007g.tar.gz
    -rw-r--r-- 1 8800 0 162187 Oct 1 14:05 tzdata2007h.tar.gz
    -rw-r--r-- 1 8800 0 162977 Nov 1 14:16 tzdata2007i.tar.gz

    While it is true that some of those source files are making relatively
    inconsequential changes, they all effect _someone_ out there. 2006g
    effected Oz and the US, while 2007h changed Egypt, Iran, Palestine,
    and Brazil. 2007i only changes Syria and Cuba.

    Old guy

  20. Re: Clock did not adjust for daylight saving

    ibuprofin@painkiller.example.tld (Moe Trin) writes:

    >On Tue, 06 Nov 2007, in the Usenet newsgroup alt.os.linux.suse, in article
    >, Pat wrote:


    >>Thanks for all the replies and suggestions. It's was interesting to
    >>read about the various issues and nuances involved with this.


    >-rw-r--r-- 1 8800 0 162977 Nov 1 14:16 tzdata2007i.tar.gz


    >That's the source of the data files (on elsie.nci.nih.gov) and opening
    >that tarball gives 19 text files needed for the 'zic' compiler to
    >create the actual timezone files your system uses. There are no less
    >than 393 timezones in those files - although clocks around the world
    >may be displaying 35 different "local" times (there are 11 non-hour
    >increment zones, such as India [+05:30], central Oz [+09:30], and
    >Newfoundland [-03:30]). Expecting the 244 nations around the world to
    >agree when to change the clocks (if at all) is hopeless.


    To be fair, much of the complexity of that file is historical data. That in
    1889 time zone structures were complex does not mean that much for today,
    but does make the tzdata file complex.


    >>I think I understand now why my clock failed to adjust for DST. My use
    >>of Windows XP is infrequent and almost entirely though VMware Server.
    >>So the "local" time I was using had no way of updating.


    >Bingo! Telling Linux that the BIOS clock is set to "localtime" means
    >that some other entity is making sure the clock is set correctly. This
    >could be windoze, or it could be you getting into the BIOS setup twice
    >a year to correct things. Most operating systems use two clocks - a
    >software clock which is what the UNIX 'date' command and most eye-candy
    >clocks on GUI desktops show, and the hardware clock in the BIOS. Most
    >O/S only look at the hardware clock at boot time using it to set the
    >starting time of the software clock. Most O/S have commands that can
    >be used to _set_ the hardware clock, but this is a user preference
    >that most Linux distributions don't use by default (windoze can be
    >set to correct the BIOS clock for DST shifts - which may or may not
    >be desirable).


    >>I've now switched it to UTC, and everything appears correct - it's
    >>showing 7:17 am, as it should. It will be interesting to see what
    >>happens in the spring though, when the time switches back again.


    >If you can tell windoze that the BIOS clock is set to UTC _and_ if


    Can you tell Windows that the bios clock is UTC? I have never heard of
    that.



    >it knows the "correct" schedule and offset, things should be fine.
    >As far as Linux is concerned, if the system is set to UTC and is
    >aware of the correct timezone names - you're home free until the
    >congress-critters get another hair out of shape and decide to mess
    >with the clock once again. As most of what they do is to give the
    >illusion of doing "something", anything is possible.




    If the congress critters do change things again, the tzdata file will be
    changed to reflect that within a day or two, and all distributions will
    have corrections published in a few months ( and fortunately the congress
    critters do refrain from passing changes that take practical effect in a
    few days. It is usually at least a year beforehand)


    > Old guy


+ Reply to Thread
Page 1 of 2 1 2 LastLast