[MiNT] MiNTLib Non-Bug

[Guido Flohr <gufl0000@stud.uni-sb.de>]

Hi,

you may encounter a strange behavior of file timestamps created or read
by recent MiNTLib versions.

You probably know that a calendar time is usually expressed as `seconds
since the epoch' and the epoch is Jan 1, 00:00 1999 UTC.  The POSIX
folks have expressed this slightly different as far as I know.  They
have said more or less: `The representation of a time_t has to be
such that Jan 1 1980 [or something like that, after 1970] is such and
such a number of seconds.'

Well, it turned out that they had forgotten the leapseconds which are
periodically inserted to correct discrepancies between atomic time and
the earth's rotation.  That is the reason why you have the subdirectories
`posix' and `right' in `/usr/share/zoneinfo'.  By default the MiNTLib
violates POSIX and takes leapseconds into account.

If you don't like that you have to edit the appropriate variables
in `configvars' of the MiNTlib.  Alternatively you may set the system
timezone with

	zic -L posix/Europe/Paris

instead of

	zic -L Europe/Paris

So, what is the strange behavior?  Old programs will get the system
time and assume that it is correct when writing timestamps.  New
programs will by default correct them by the appropriate number of
leapseconds (the difference is 21 seconds today).

If you get a new version of make, that may cause a little trouble.
If an old program creates a file and make checks the timestamp of
that file less then 21 seconds after it was modified, make will
complain that the file has a modification time in the future.
This behavior will vanish gradually, as the other programs get
rebuilt.

Maybe it would be better if the MiNTLib always ignored leapseconds when
dealing with timestamps.  But the preferred solution, at least for file
systems that are only available under MiNT (minix, ext2, fnramfs, spin?,
pipe, proc, shm, ...) would be if the kernel would also use UTC for
timestamps.  There is a potential problem with timestamps in local time.  
In countries that use summertime, there is usually a Sunday when the
clocks are turned back one a hour at three o'clock in the morning.  If you
have a file that has a timestamp of 2:30 of that day there is no way to
find out, if it was modified before or after the clocks were turned back.
BTW, this was the reason for a bug in Windows 95.  No, stop, before you
start laughing: For the same reason any implementation of cron under MiNT
will fail to deal correctly with jobs that are scheduled during these two
hours that exist twice.

Ciao

Guido
-- 
http://stud.uni-sb.de/~gufl0000/
mailto:gufl0000@stud.uni-sb.de
      \   |__
       ####  \ /    Total solar eclipse of 1999 August 11
     ######## |_    over Saarbr?cken/Germany.
     ######## |     Countdown: 08d20h50m50s.
       ####__/ \
      /   |