Rob Janssen wrote:
Actually, on many modern Unix/Linux systems there is no need to reboot
because the timezone information is no longer stored in the
environment, and newer versions of the libraries can detect that the
setting has changed and re-adjust accordingly.
Thanks for your insight, but you are wrong about Windows.
Windows uses UTC throughout internally, and the time zone setting
controls how the internal UTC time is presented to the user. As the
file timestamps (with NTFS etc.) are stored in UTC, you would
/expect/ the presented timestamp to change when DST is, or is not
present. It's not a bug, but correct behaviour, IMHO. [Otherwise
you could have two files created an hour apart showing the same
timestamp].
That is because Windows does not keep historic information about DST,
but only has a single timezone/dst rule and current UTC offset.
Unix/Linux keeps a separate offset (via a configuration database) for
each time interval where DST has or hasn't been in effect.
So it knows that a file created at 4 o'clock on the saturday before a
DST change has another UTC offset to apply when showing its timestamp
than a file created on the sunday.
Two files each showing 4PM a day apart may be 23h or 25h different in
creation time in this case.
This also fixes the case where DST rules have changed historically,
i.e. it knows that the begin and end of DST have changed in Europe in
'95. Windows95 had to be patched at the right moment to cover that,
and consequently misrepresented the timestamp on older files, but
Unix/Linux "knew" beforehand that this would change (it was decided a
few years before) and still knows about it.
So no, I don't expect a timestamp for a file to change when DST goes
into effect. On Unix/Linux, it doesn't. I was surprised to see that
it /did/ change in Windows, and I have seen several problems with it
(especially in the days that Pre-NT versions were still common)
Rob
Thanks, Rob.
I still don't like the ambiguity introduced by the Unix method of working,
but I can guess that people who don't expect the presentation to change
between daylight and standard time on Windows might be confused as well!
Having a separate historical database gives Unix more flexibility,
certainly.
I don't recall any problem here in Europe in 1995 with Windows 95, but in
any case they toy versions of Windows had too many compromises for my
linking. I've been using Windows NT and its derivatives since 1992...
David
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
