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

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

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.

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.

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?

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.

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

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

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

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

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

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

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

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

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

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

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

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

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