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). Any suggestions? Cheers, Simon "You can tell whether a man is clever by his answers. You can tell whether a man is wise by his questions." — Naguib Mahfouz
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 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. But, again, setting the clock to UTC is the best long term solution
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
I have two computers here. One is set to UTC and the other to local time. Both successfully changed to standard time.
-----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-----
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. Fred
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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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? 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. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFRePvtTMYHG2NR9URAhHjAJ4ohWc8v99vsAv6LVpEYSx4aKJSHwCeOX2v jR+i9JwoCJHRvCZ68wsp8dw= =J73Z -----END PGP SIGNATURE-----
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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFRfoktTMYHG2NR9URAkzFAJ9S5CIkHIeJ0K3N+RKg18blgv7esACghjr6 /YZKOHbck2Xy8KiKQAHLZCs= =6hTE -----END PGP SIGNATURE-----
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?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-10-30 at 10:02 -0500, James Knott wrote:
That's the CMOS clock.
And is that not hardware? Or are you thinking of some external clock?
Did I say it wasn't? - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFRhiltTMYHG2NR9URAskzAJ9OoXy9veKHNrDyjN1NPOeqUhnNTACfdjF6 N3KfRuQwJ1jsssbxCdkVPx8= =cHC7 -----END PGP SIGNATURE-----
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.
Dylan wrote:
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.
While Yast supports such a clock, it's not what most people think of, when referring to a hardware clock. Also the settings for those clocks are in the NTP section, not the basic clock configuration.
-----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: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? -- Steve Boddy
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-10-30 at 12:47 +0100, Stephen Boddy wrote:
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?
That's not the system time. That's the CMOS clock, some times called "Hardware Clock". They are different. System time is always UTC. The CMOS clock no. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFRemptTMYHG2NR9URAkmGAJwLi6VXW8mC9d2qpPP+jMohNB45JQCdE/Bz QIsiP0/TfD7gybLRwWwj92w= =sRjg -----END PGP SIGNATURE-----
"Carlos E. R." <robin.listas@telefonica.net> 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.
On 31/10/06 06:09, Alexandr Malusek wrote:
"Carlos E. R." <robin.listas@telefonica.net> 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.
Darryl Gregorash <raven@accesscomm.ca> writes:
On 31/10/06 06:09, Alexandr Malusek wrote:
"Carlos E. R." <robin.listas@telefonica.net> 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.
On 31/10/06 06:48, Alexandr Malusek wrote:
Darryl Gregorash <raven@accesscomm.ca> writes:
On 31/10/06 06:09, Alexandr Malusek wrote:
"Carlos E. R." <robin.listas@telefonica.net> 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.
Oh, the atomic second. These are all three very different things, you know.
Darryl Gregorash wrote:
On 31/10/06 06:09, Alexandr Malusek wrote:
"Carlos E. R." <robin.listas@telefonica.net> 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 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 There is only one system clock that keeps time in a human format, and that is the CMOS clock
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-10-30 at 18:47 +0100, 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
There is only one system clock that keeps time in a human format, and that is the CMOS clock
The kernel timer is the system clock, ie, the operating system clock (I consider the kernel part of the OS). I should probably have used that full name to avoid confusion. Another name is software clock, although it is based on a programmable timer chip that interrupts periodically the cpu - thus hardware - and then the software counts the interrupts - thus software -. But the cmos clock, or bios clock, or battery backed clock, can probably be called hardware clock as it runs without help from the computer or its software. As it is "stand alone", it is not a "system" clock, or rather "OS clock". Is that clearer now? :-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFRl5RtTMYHG2NR9URAlaQAJ9caj1OQoVKIGGzd1sHJw94A9/v+gCfaYtg ZDFSuzJIvttL/z2vj27MOvI= =vK87 -----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. -- ___ _ _ _ ____ _ _ _ | | | | [__ | | | |___ |_|_| ___] | \/
-----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. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFR6zotTMYHG2NR9URAnI9AJ4uo/Rz0f8dI5XnUHPDe3iCjlvEoQCfWXnS R3C++tRkAUWohAt6OqUwig8= =sUOH -----END PGP SIGNATURE-----
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, -- ___ _ _ _ ____ _ _ _ | | | | [__ | | | |___ |_|_| ___] | \/
Carl William Spitzer IV wrote:
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.
No, UTC does not mess up the clock. Windows messes up, because it's so clueless.
-----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-----
Carlos E. R. wrote:
The Wednesday 2006-11-01 at 08:21 -0500, James Knott wrote:
<SNIP> 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.
I agree, they're not clueless. But I believe their methods are warped by greed. I haven't, lately, seen them worry about being compatible with anything but forcing the user to spend more money. When they introduced XP, most of my favorite software became useless, except on the older machine and OS. That's why I converted to Linux. (Besides, XP didn't work right, and I couldn't get the quality of help that I have from the SuSE people). I think Windose hasn't changed their way of handling time, because there's no money in it. -- ED --
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. -- ___ _ _ _ ____ _ _ _ | | | | [__ | | | |___ |_|_| ___] | \/
Simon Roberts wrote:
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).
Running an ntp client can not be the cause of the problem, since it automatically corrects for the change. Are you *sure* you're running one? Or is your internet connection somehow not what it should be? Regards, -- Jos van Kan registered Linux user #152704
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).
Any suggestions?
It changed fine for me on two different computers.
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.
If your linux machine does not nothice the daylight saving time change, its timezone is not properly configured. Check your timezone setting and update as needed. On the other hand, some timezone definitions have been changed this year, hence, you might need an update here. If the machine is dual-boot with M$Windows and has the bios-clock reflect local time, then boot to M$Windows and have that change the biosclock. On the linux side, once again, nothing is needed.
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.
Linux (and unix) donnot use local time: internal, all time is in epoc: seconds since 1 januari 1970 00:00 UTC (or GMT). Only the moment the time is displayed for human beings, the time is calculated according to the timezone settings.
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).
ntp also uses epoc, hence no problem there.
Any suggestions?
Cheers, Simon
"You can tell whether a man is clever by his answers. You can tell whether a man is wise by his questions." — Naguib Mahfouz
On Sun, 2006-10-29 at 13:41 -0800, 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 kno
I have always fixed it in bios when I boot the machine. Much easier in cmos and this is on oldware where the cmos is unaware of DST. -- ___ _ _ _ ____ _ _ _ | | | | [__ | | | |___ |_|_| ___] | \/
participants (15)
-
Alexandr Malusek -
Anders Johansson -
Basil Chupin -
Carl William Spitzer IV -
Carlos E. R. -
Corne Beerse -
Darryl Gregorash -
Dylan -
Ed McCanless -
James Knott -
Jos van Kan -
PerfectReign -
Simon Roberts -
Stephen Boddy -
Stevens