-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-10-29 at 22:46 +0100, Anders Johansson wrote:

Do you have your system clock set to local time? If you do, linux won't attempt to correct for DST

...

Any suggestions?

In linux, always set the system clock to UTC, and leave the timezone handling to the OS. Then the DST conversion will happen seamlessly

Er... in Linux the system clock always uses UTC time, regardless of what the users' settings are. It is the CMOS clock that can use UTC or Local Time, for the use of that other OS when you double boot.

A short term solution could also be to run ntpdate against a trusted ntp server, which should set your clock to the correct time again.

The NTP service always uses UTC time. It will not correct the displayed time. However, if the system clock is wrong because of mistaken assumptions during bootup setting, then yes, that will work (See * below). Don't confuse the time displayed to the user with the system internal time, which is always in UTC. Different users of the same system may have different times shown. As a side effect, there is no daylight adjustments at all to the system clock that can be done, UTC doesn't change. However, the settings of the time zone and daylight savings of each user can be modified. (*) A possibility is a mismatch in the CMOS clock having adjusted itself for daylight savings or not, booting after the hour when the change occurs, and the boot up procedure mistakenly thinking the time is in DLS or not.

But, again, setting the clock to UTC is the best long term solution

That's correct, because in that case the time setting procedure does not need logic corrections for DLS. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFRSxDtTMYHG2NR9URAi12AJ9rETke0EjKYl/nbyZ/2rH6u3KHggCeO77p ROxW0rXzelPZvcdJ9L4108E= =SZff -----END PGP SIGNATURE-----

Stevens wrote:

On Sunday 29 October 2006 16:33, Carlos E. R. wrote:

...

Don't confuse the time displayed to the user with the system internal time, which is always in UTC. Different users of the same system may have different times shown.

Carlos:

Suse 9.1 here and the system internal time is definitely NOT in UTC. It may have been at install time, but after a little patience and a lot of beatings I finally got it to work like I wanted, which is local time. Since it is all relative anyway, it makes very little real difference except that I like it better.

IIRC, Unix systems generally set the hardware clock to UTC. However, if you dual boot to Windows, you have to use local time.

Carlos E. R. wrote:

The Sunday 2006-10-29 at 21:35 -0500, James Knott wrote:

...

...

Suse 9.1 here and the system internal time is definitely NOT in UTC. It may have been at install time, but after a little patience and a lot of beatings I finally got it to work like I wanted, which is local time. Since it is all relative anyway, it makes very little real difference except that I like it better. IIRC, Unix systems generally set the hardware clock to UTC. However, if you dual boot to Windows, you have to use local time.

You are confusing terms.

Which is the "hardware clock" for you?

There is only one hardware clock that I'm aware of and that's the one built into the mom board. Yast gives you the option of setting it to UTC or local time. What other hardware clock did you have in mind?

Internal, system, clock is _always_ utc. There is no configuration anywhere to change that, there is no choice at all. This clock is simply a counter maintained by adding a number to it in a program (ie, the kernel).

Notice that the time displayed to the user is not the system time.

The CMOS clock, battery backed, or bios clock, perhaps "hardware clock", can use local or utc, there you have a choice. This clock is read during boot by the operating system to set the system time. If it is utc, then it is straigth away. If the cmos is local, then the utc has to be calculated first, corrected for dls, and the result is used to set system time.

Carlos E. R. wrote:

The Monday 2006-10-30 at 07:50 -0500, James Knott wrote:

...

...

Which is the "hardware clock" for you? There is only one hardware clock that I'm aware of and that's the one built into the mom board. Yast gives you the option of setting it to UTC or local time. What other hardware clock did you have in mind?

That's the CMOS clock.

And is that not hardware? Or are you thinking of some external clock?

On Monday 30 October 2006 12:50, James Knott wrote:

There is only one hardware clock that I'm aware of and that's the one built into the mom board. Yast gives you the option of setting it to UTC or local time. What other hardware clock did you have in mind?

A machine may have an addon hardware clock which gets a time reference from the National Time Code or GPS for example.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-10-29 at 20:32 -0600, Stevens wrote:

Carlos:

Suse 9.1 here and the system internal time is definitely NOT in UTC.

How much would you bet? :-P That is utterly imposible, no matter what.

It may have been at install time, but after a little patience and a lot of beatings I finally got it to work like I wanted, which is local time. Since it is all relative anyway, it makes very little real difference except that I like it better.

And what command do you use to see the internal system time, ein? - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFReEttTMYHG2NR9URAjz+AJ99dkQYrDmIigz3N+r+geNLwp1tRgCeIXS1 qLxvF6LZ2XL++QFO7qbJ/HY= =jfbS -----END PGP SIGNATURE-----

On Monday 30 October 2006 11:47, Stephen Boddy wrote:

On Monday 30 October 2006 11:25, Carlos E. R. wrote:

...

The Sunday 2006-10-29 at 20:32 -0600, Stevens wrote:

...

Carlos:

Suse 9.1 here and the system internal time is definitely NOT in UTC.

How much would you bet? :-P

I'd bet a fair amount actually... ;-)

...

That is utterly imposible, no matter what.

Really? So when I go to YaST's "Date and Time" module, and click on the "Hardware Clock Set To" dropdown, I'm guessing the "Local Time" option is a lie?

...

...

It may have been at install time, but after a little patience and a lot of beatings I finally got it to work like I wanted, which is local time. Since it is all relative anyway, it makes very little real difference except that I like it better.

And what command do you use to see the internal system time, ein?

Erm... date?

OK, ignore this Carlos, and don't go jumping all over me. I read system as hardware, which means I'm just wasting electrons. -- Steve Boddy

"Carlos E. R." writes:

... System time is always UTC. ...

UTC uses the concept of leap seconds. Internal kernel clock ticks measure the number of seconds since midnight UTC, January 1, 1970 (no leap seconds are taken into account). The conversion from the internal clock ticks to UTC is performed via glib. In other words, the statement "system time is always UTC" is wrong. -- A.M.

Darryl Gregorash writes:

On 31/10/06 06:09, Alexandr Malusek wrote:

...

"Carlos E. R." writes:

...

... System time is always UTC. ...

UTC uses the concept of leap seconds. Internal kernel clock ticks measure the number of seconds since midnight UTC, January 1, 1970...

Are those sidereal seconds or mean solar seconds?

Well, the second is a well defined physical unit in SI (see e.g. http://en.wikipedia.org/wiki/Second). Something must be terribly wrong with the acceptance of SI in Canada if you ask such a question. -- A.M.

Darryl Gregorash wrote:

On 31/10/06 06:09, Alexandr Malusek wrote:

...

"Carlos E. R." writes:

...

... System time is always UTC. ...

UTC uses the concept of leap seconds. Internal kernel clock ticks measure the number of seconds since midnight UTC, January 1, 1970...

Are those sidereal seconds or mean solar seconds? Personally, I have always preferred the sidereal second, but most people seem to have a silly fixation on the sun. It is quite unnecessary, really.

Can we get back to the topic at hand, which is: how does the OP get his system clock to display the correct time?

Oh wait, I already answered that question.. OK, carry on.

Stirrer. :-D Cheers. -- I'm dangerous when I know what I'm doing.

On Mon, October 30, 2006 9:47 am, Anders Johansson wrote:

On Sunday 29 October 2006 23:33, Carlos E. R. wrote:

...

Er... in Linux the system clock always uses UTC time, regardless of what the users' settings are. It is the CMOS clock that can use UTC or Local Time, for the use of that other OS when you double boot.

With this definition I'm at a loss what you mean by system clock then.

The internal kernel timer counts the number of seconds since January 1 1970

Yes. The dual boot thingy is - IIRC - because DOS/Windows kept time differently than does WinNT (a.k.a. XP/Vista), which is "a better Unix than Unix." It used to cause me no end of frustration on my 486 laptops which ran DOS and WinNT 3.51 on different partitions.

There is only one system clock that keeps time in a human format, and that is the CMOS clock

Well, not really, unless you consider binary a "human format". :) Now, if they'd only figure out why we do DST nowdays... -- Kai Ponte www.perfectreign.com || www.4thedadz.com remember - a turn signal is a statement, not a request

On Sun, 2006-10-29 at 22:46 +0100, Anders Johansson wrote:

On Sunday 29 October 2006 22:41, Simon Roberts wrote:

...

Hi all,

This seems really silly, but Daylight Saving time is ended, and I can't work out how to get my computer to notice.

I thought it would have just known, as has happened in the past, but it's still concienciously showing MDT time rather than MST. I tried to use Yast to correct this, and the only thing on offer to me are other major timezones, nothing for Daylight saving.

It might be part of the puzzle, though I don't quite see how, that I run an ntp client (because my laptop's clock is dreadfully inaccurate--I suspect a failing CMOS support battery or something).

Do you have your system clock set to local time? If you do, linux won't attempt to correct for DST

...

Any suggestions?

In linux, always set the system clock to UTC, and leave the timezone handling to the OS. Then the DST conversion will happen seamlessly

Caution UTC messes up the clock if you multiboot with windows. -- ___ _ _ _ ____ _ _ _ | | | | [__ | | | |___ |_|_| ___] | \/

On Tue, 2006-10-31 at 21:07 +0100, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

The Monday 2006-10-30 at 16:49 -0800, Carl William Spitzer IV wrote:

...

Caution UTC messes up the clock if you multiboot with windows.

Correct. I have my windows in UTC too.

Not so for legacy windows. I am not sure about FreeDOS, -- ___ _ _ _ ____ _ _ _ | | | | [__ | | | |___ |_|_| ___] | \/

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2006-11-01 at 08:21 -0500, James Knott wrote:

...

Caution UTC messes up the clock if you multiboot with windows.

No, UTC does not mess up the clock. Windows messes up, because it's so clueless.

It is not clueless. They just decided to use local time when Dos was small and single tasked, and has stuck with it in windows. A wrong decision nowdays, of course. Probably maintained for compatibility, and I guess it complicates things for them. The same as many decisions they took initially, of course. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFSKSZtTMYHG2NR9URAlEtAJ4mouRoHIqFjS+Z+kIklCMLDc4oswCeOuDl Q4xFNF06G2MSg3kUImgZWTI= =l0Fh -----END PGP SIGNATURE-----

On Sun, 2006-10-29 at 22:46 +0100, Anders Johansson wrote:

On Sunday 29 October 2006 22:41, Simon Roberts wrote:

...

Hi all,

This seems really silly, but Daylight Saving time is ended, and I can't work out how to get my computer to notice.

I thought it would have just known, as has happened in the past, but it's still concienciously showing MDT time rather than MST. I tried to use Yast to correct this, and the only thing on offer to me are other major timezones, nothing for Daylight saving.

It might be part of the puzzle, though I don't quite see how, that I run an ntp client (because my laptop's clock is dreadfully inaccurate--I suspect a failing CMOS support battery or something).

Do you have your system clock set to local time? If you do, linux won't attempt to correct for DST

...

Any suggestions?

In linux, always set the system clock to UTC, and leave the timezone handling to the OS. Then the DST conversion will happen seamlessly

Caution UTC messes up the clock if you multiboot with windows. -- ___ _ _ _ ____ _ _ _ | | | | [__ | | | |___ |_|_| ___] | \/