Rsync sending files that haven't been updated.

[hh.eu at gmx.de]

On 2008-08-01 at 19:49 Paul Slootman wrote:

> On Fri 01 Aug 2008, becca23 wrote:
>>
>> Yes it does appear that I have some sort of UTC disaster on my  
>> hands. For
>> testing, both the Linux and Windows machine are virtual machines  
>> on a VMware
>> server. The current UTC time for that one is 6:39. The Linux UTC  
>> time is
>> listed as 5:39 which agrees with worldtimeserver.com. The windows  
>> machine is
>> one or two hours ahead of that depending on whether I set it for  
>> daylight
>> savings time or not. Help?!
>
> You will probably need to set the windows timezone as UTC (I think
> Iceland will do :-), as AFAIK windows expects the "CMOS  
> clock" (faked by
> vmware) to be in local time. Perhaps vmware offers an option to fake
> local time there...

Windows does expect the "hardware clock" to be in *local time*. Of  
course you can set a timezone in Windows, too, but with the effect  
that a change to daylight savings time will cause Windows to also  
change the hardware clock by one hour (so that it still shows the  
local time).

On most (all?) Unix/Linux systems, on the other hand, the convention  
is to always have the hardware clock set to UTC. It is only the  
software in the operating system that does the conversion for the  
display of date/time values and takes care of the difference between  
your chosen time zone and UTC. In other words, the hardware clock  
will always remain to be set in UTC.

So if you have a dual-boot computer with both systems installed, they  
will not play well together. I know that the Debian installer is  
aware of this problem. It specifically gives the following  
suggestions when installing Debian:

1) If you don't plan to install Windows on the same machine, follow  
the Unix convention and set your hardware clock to UTC (and tell the  
installer about it).

2) If you plan to install Windows on the same machine, set the  
hardware clock to your local time so that Windows will be happy. Tell  
the Debian installer about it, Debian will then try to handle this  
appropriately.

Of course method 2) cannot really work. E.g. suppose you initially  
have the same time zone set in Debian and Windows, but then go to  
another place (say on a holiday or a business trip -- imagine you  
have a laptop computer). You will want Windows to show the correct  
local time and change the time zone, with the effect of changing the  
hardware clock. Then, a few days later, you boot into Debian, which  
still thinks that the hardware clock is in your old time zone, so it  
calculates an incorrect value for UTC from that and thus shows you an  
incorrect local time, too.

(Yes, you can then change the time in Debian, but before you do that,  
there are periods where the UTC is incorrect. If both systems are  
running as virtual systems, incorrect times will be used for as long  
as you haven't matched both systems' settings. If the Unix convention  
were used on both systems, local time might be displayed  
'incorrectly' when you forget to change to an appropriate time zone  
on one systems, but at least the 'absolute time scale' (UTC) will  
remain correct in all cases on both systems and can be used, e.g. to  
calculate durations or comparisons of time stamps etc. correctly.  
[Actually, even then the displayed local time will not be really  
incorrect if you look at the full format which includes the  
information about the time difference between local time and UTC.])

Anyway, this is how it works, I believe. I have never used VMware,  
but in essence your problem will be related to this. The "hardware  
clock" for the virtual machines is provided by the host system  
(VMware), but I am not sure if VMware uses the real CMOS clock of the  
machine it is running on or a separate value it calculates, based on  
the settings of the host OS.

As always, things were much simpler if there was a common (and  
sensible) standard across the different systems.

HTH
-M