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
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
