>>>>> "TN" == Tony Nugent <[EMAIL PROTECTED]> writes:
TN> System: i386 RedHat 5.1 (glibc6)
TN> I have not seen this problem myself, but I am passing this on as I am the
TN> linux support person here at USQ. This is what has been described to me,
TN> and I haven't a clue as to why this is happening. However, I suspect that
TN> it could be a glibc issue...
TN> When linux boots up and uses the system time, it all looks ok. We are
TN> GMT+10 hours here (Queensland Australia), and the bios clock is set at the
TN> local time. /etc/localtime is a symlink pointing to the correct
TN> /usr/share/zoneinfo/ file.
TN> Write a file to a vfat-mounted dos partition with linux and the timestamps
TN> look good - the correct (current) time as would be expected. (Of course,
TN> same for timestamps on new files on the linux filesystem).
TN> Boot into windows and the timestamps on any of these files are 10 hours
TN> behind!
TN> Create new files with the current timestamp with windose and all looks
TN> good. But boot into linux and look at those files -- they are 10 hours
TN> ahead! (Which means thay can be set for a time in the future).
TN> This is obviously a problem related to the local time difference, but what
TN> is going on?
TN> Is windows at fault, or linux? Or have we just discovered the secrets of a
TN> time-travel machine?? :-)
Looking at 2.0.32 this is what I see.
The kernel keeps track of the local time, which is set bye the
system call settimeofday.
When a fat filesystem date is converted to a unix date minuteswest minutes are added
to the time.
When a unix date is converted to a fat filesystem date minuteswest are subtracted
from the current time.
So it appears that the linux kernel has the wrong idea of the local time zone, a la
minueswest.
As I understand it the first call to settimeofday that includes time zone
information must have the correct time zone set, to give linux the proper
system time (from the real time clock). So the time zone got set
right at least once.
For machines with clocks in UTC the first call to settimeofday with a
time zone specified must not set a time zone offset (minuteswest).
All further calls to settimeofday (with a time zone specified) just
affect the kernel's notion of local time.
So a call to settimeofday with an appropriate time zone value should
fix the problem. Why this doesn't happen automatically I don't know.
I hope this helps,
Eric
