All my clocks are off time.

[the vj]

I have 5 macintoshes, I believe just one has the correct timing. The rest doesn't. Some has pather and others have leopard.

I have 1 Mac Pro and one Mac Book Pro, booth with boothcamp. They are loosing time and I know that is a common issue when using boothcamp.

But I have 1 12" powerbook with the same problem running panther.

The quad G5 and the other 12" PB are running just fine.

So, is not a leopard only problem, is nota boothcamp only problem.

Any ideas?

Thanx

 

[SilentPanda]

Do you have them all set up to get the time from the internet?

 

[the vj]

Do you have them all set up to get the time from the internet?

I used to but it give me the wrong timing. I unchecked the option, set the right time, saved to prevent further changes and I get the same problem after 2 restarts or so. One computer os 5 hours off and the other one 3.

 

[larkost]

There are three possible issues here:

1 - Windows will re-set the hardware clock to the timezone it is in. Every other OS out there uses the clock as UTF, and then calculates the adjust for the time-zone it is in. The latter behavior is much better in all sorts of situations (crossing time zones, durring daylight savings time changes, etc), but Microsoft painted themselves into a corner a long time ago and can't find their way out

However, the paint is long since dry, and you can change this behavior with no-known current issues by making a change in the registry:

HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal

Set that to a Dword of 1.

2 - If your computes are losing time constantly, that probably means that the CMOS battery is going bad. You will need to replace that.

3 - Could it be possible that whatever you are using to determine the "correct" time is actually the thing that is off? If your computers are set to time-sync with NTP, then they should be correct.

 

[Rodimus Prime]

There are three possible issues here:

1 - Windows will re-set the hardware clock to the timezone it is in. Every other OS out there uses the clock as UTF, and then calculates the adjust for the time-zone it is in. The latter behavior is much better in all sorts of situations (crossing time zones, durring daylight savings time changes, etc), but Microsoft painted themselves into a corner a long time ago and can't find their way out

However, the paint is long since dry, and you can change this behavior with no-known current issues by making a change in the registry:

HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal

Set that to a Dword of 1.

2 - If your computes are losing time constantly, that probably means that the CMOS battery is going bad. You will need to replace that.

3 - Could it be possible that whatever you are using to determine the "correct" time is actually the thing that is off? If your computers are set to time-sync with NTP, then they should be correct.

I might like to point out that on your point 1 that the other OS use a Unix base code hence the use the UTF. Microsoft is NT based. So really it comes down to the base code and hell if you go that route then you will see that their are more base codes that mess with the hardware clock than the other way around mind you Microsoft made over 1/2 of the base codes.

It been argue before that really does not matter which way you go. Both work out just fine. Each has their advantages and draw backs. Personally I like the hardware clock route because if I am messing around in the BIOS before the OS boots up it is easier to tell what the time is than it is to figure out all in my head. Very handing for setting up a boot up time. No figuring required and it automatically adjust to DL time or time zones. I do not have to in and edit at the BOIS level every time DL or a time zone change happens.

 

[JediMeister]

Something applicable for 10.5, doesn't seem there's anything that should happen in Panther similarly.

 

[larkost]

I might like to point out that on your point 1 that the other OS use a Unix base code hence the use the UTF. Microsoft is NT based. So really it comes down to the base code and hell if you go that route then you will see that their are more base codes that mess with the hardware clock than the other way around mind you Microsoft made over 1/2 of the base codes.

It been argue before that really does not matter which way you go. Both work out just fine. Each has their advantages and draw backs. Personally I like the hardware clock route because if I am messing around in the BIOS before the OS boots up it is easier to tell what the time is than it is to figure out all in my head. Very handing for setting up a boot up time. No figuring required and it automatically adjust to DL time or time zones. I do not have to in and edit at the BOIS level every time DL or a time zone change happens.

There are real and solid advantages to not keeping the hardware clock synced with the "wall clock". Most of them cluster around what I hinted at:

1) If you walk a computer over a time-zone boundary things still make sense. You can grab a timestamp before it, walk over the boundary (adjust your clock to what it should be), and grab a second time-stamp. The two results make sense if you are keeping UTC (sorry... used the wrong acronym before), but if you are using local time zone, then the first one can be after the second.

2) The same circumstances happen when you are in a time-zone that keeps daylight savings time. You get weird results right around the the switch. So every application has to be aware of this, and also be aware when time-zone change dates change... in every application.

3) If you are working on applications that need to communicate across time-zones then you need to take care of all of that on the application level, plus remember all the time-zone issues. If your clock is UTC, then you don't have to worry about this in every application.

I have been hammering how every application needs to be aware of this. The demonstration of this would be MS-Office which does everything in "local" time. There have been specific patches to get it working when the time-zone changes happened recently, and then there were specific versions of that patch for people who were in counties that did not change. And there is always someone in South-America who complains that theirs is screwed up. Keeping things in UTC avoids this issue. Everything is handled in one spot, and there is one set of adjust-files that can be updated to handle all of that for every application on the system.