I noticed my clock was an hour off today. Then it hit me, this used to be the day that DST would ‘fall back’ an hour. I don’t know if there’s a setting for me to set to choose which DST date to use or what.
Its not a big problem, I just bumped the hour by 1, but just thought I’d make mention if its a bug or something.
When you have set your correct local timezone at installation (or later) this should all work as you local laws are.
Thus check if you have set correct: YaST > System > Date and time.
And next time take the effort of telling what level of openSUSE you use. And where you see the problem, in a desktop, then please which one. It may not be of interest in this case, but you better leave that decission to those who try to help you.
Oh, haha, sorry about that. Im using 11.4 32bit with Gnome 2.
I looked in YaST and the region and time zones are set correctly (USA and Mountain). The UTC box is unchecked, but I do occasionally boot into XP so I left that alone.
Thanks for the response, Henk. And also for pointing out where to find the settings.
>
> Oh, haha, sorry about that. Im using 11.4 32bit with Gnome 2.
>
> I looked in YaST and the region and time zones are set correctly (USA
> and Mountain). The UTC box is unchecked, but I do occasionally boot into
> XP so I left that alone.
>
> Thanks for the response, Henk. And also for pointing out where to find
> the settings.
>
There is a setting for windows which makes it possible to use the hardware
clock set to UTC also in windows.
Create a key (if it does not already exit) with the registry editor as dword
and set it to 1 (one), the keyname is
HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal
should also work with XP
–
PC: oS 11.4 64 bit | Intel Core i7-2600@3.40GHz | KDE 4.6.0 | GeForce GT 420
| 16GB Ram
Eee PC 1201n: oS 11.4 64 bit | Intel Atom 330@1.60GHz | KDE 4.7.2 | nVidia
ION | 3GB Ram
When you are running only Linux, you should use UTC for the clock. Then you can be blissfully unaware of DST changes, it will be taken care of automatically.
When you dual boot, normally you use local time for the clock. It will then be off at DST changes. Either fix the time at the BIOS; or boot into Windows once and let it change the clock; or boot into Linux and assuming you get time from NTP, let it fix itself, then shutdown to save into the BIOS clock.
From the looks of previous posts, Windows is belatedly implementing the sensible algorithm.
On 2011-10-31 21:36, Wandering Voice wrote:
>
> Oh, haha, sorry about that. Im using 11.4 32bit with Gnome 2.
>
> I looked in YaST and the region and time zones are set correctly (USA
> and Mountain). The UTC box is unchecked, but I do occasionally boot into
> XP so I left that alone.
The use of XP can explain the problem.
To check if the time is correct, just issue the commands “date” and “date
–iso=seconds”. The first should be the local time, and the second the
Universal Time Coordinated, and both should be correct.
If UTC is correct, but local is not, then your locale is incorrect.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
>
> It does work fine with Vista and Windows 7. However, best to tell
> Windows to never update with an NTP timeserver, and do your clock
> updating in linux.
>
Thanks for clarifying, I was not aware of the issue with XP with that
workaround.
–
PC: oS 11.4 64 bit | Intel Core i7-2600@3.40GHz | KDE 4.6.0 | GeForce GT 420
| 16GB Ram
Eee PC 1201n: oS 11.4 64 bit | Intel Atom 330@1.60GHz | KDE 4.7.2 | nVidia
ION | 3GB Ram
I tried it with XP on my desktop and on a laptop. It was fine on the desktop, because I could configure that to never sleep. But I can’t do that with a laptop, in case it is on battery. And when it sleeps, it wakes up with the wrong time.
On my newer laptop, with Windows 7, it is working fine. But there was one problem. Last spring, shortly after the change to DST, I noticed that it was one hour out. I was able to track that down to Windows 7 setting time from an NTP timeserver. I’m not sure, but I think it applying DST time to UTC, setting the clock off by one hour. But when it interprets the clock to set localtime, it doesn’t assume DST for UTC. So the clock is one hour off, and after adjusting for local time, that is also one hour off. Disabling timesetting from an NTP server fixed that. As long as I keep the time set only when booted to linux, it will also have correct time on Windows.
Windows may be belatedly using the right algorithm, but it still did not have it right last spring. I haven’t checked since.
> On my newer laptop, with Windows 7, it is working fine. But there was
> one problem. Last spring, shortly after the change to DST, I noticed
> that it was one hour out. I was able to track that down to Windows 7
> setting time from an NTP timeserver. I’m not sure, but I think it
> applying DST time to UTC, setting the clock off by one hour. But when
> it interprets the clock to set localtime, it doesn’t assume DST for UTC.
> So the clock is one hour off, and after adjusting for local time, that
> is also one hour off. Disabling timesetting from an NTP server fixed
> that. As long as I keep the time set only when booted to linux, it will
> also have correct time on Windows.
>
Same here the netbook has also a windows 7 on it and the setting works well
for me, I did not run into the problem you have seen since my win 7 is not
set to use NTP. But good to know that one has to be carefull if it is.
Btw I boot not often into it, I just left it intact for the rare cases when
I really need a windows application (and running a virtualized windows on
the netbook is too heavy).
–
PC: oS 11.4 64 bit | Intel Core i7-2600@3.40GHz | KDE 4.6.0 | GeForce GT 420
| 16GB Ram
Eee PC 1201n: oS 11.4 64 bit | Intel Atom 330@1.60GHz | KDE 4.7.2 | nVidia
ION | 3GB Ram
On 2011-11-01 02:26, nrickert wrote:
> Windows may be belatedly using the right algorithm, but it still did
> not have it right last spring. I haven’t checked since.
IMO that registry change is not reliable, Windows is not designed to work
that way. It is better to configure Linux instead to treat the CMOS clock
as local time, because Linux is designed to cope with that Windows
idiosyncrasy.
However, you have to be careful that Windows will change that local time
one hour up or down due to DST and Linux will be affected as well.
It is a nuisance we have to live with when we double boot.
Those machines that never boot Windows are of course better with the cmos
clock as UTC.
(Even those that double boot to different Windows versions have this kind
of problem)
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
>Wandering Voice wrote:
>
>>
>> Oh, haha, sorry about that. Im using 11.4 32bit with Gnome 2.
>>
>> I looked in YaST and the region and time zones are set correctly (USA
>> and Mountain). The UTC box is unchecked, but I do occasionally boot into
>> XP so I left that alone.
>>
>> Thanks for the response, Henk. And also for pointing out where to find
>> the settings.
>>
>There is a setting for windows which makes it possible to use the hardware
>clock set to UTC also in windows.
>Create a key (if it does not already exit) with the registry editor as dword
>and set it to 1 (one), the keyname is
>HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal
>should also work with XP
Thanks. I can finally switch now that i know that.
>On 2011-10-31 21:36, Wandering Voice wrote:
>>
>> Oh, haha, sorry about that. Im using 11.4 32bit with Gnome 2.
>>
>> I looked in YaST and the region and time zones are set correctly (USA
>> and Mountain). The UTC box is unchecked, but I do occasionally boot into
>> XP so I left that alone.
>
>The use of XP can explain the problem.
>
>To check if the time is correct, just issue the commands “date” and “date
>–iso=seconds”. The first should be the local time, and the second the
>Universal Time Coordinated, and both should be correct.
>
>If UTC is correct, but local is not, then your locale is incorrect.
And it is more finely defined than just Mountain time, see Arizona (mostly
no DST).