Re: [MiNT] timezone change

[Guido Flohr <guido@freemint.de>]

On Wed, Mar 29, 2000 at 11:37:39PM -0800, josephus wrote:
> > With a recent filesystem, a recent kernel and a recent libc the filesystem
> > simply passes the timestamp to the kernel, the kernel passes it to the
> > application and the application converts it once into a form that the user
> > understands.  This is efficient and works.  Your system is necessarily
> > inaccurate and highly inefficient.
> > 
> 
> I'm sorry.  I thought this is what I said.   Internal system time and
> RTC and Tos are different time mechanisms.   I understand that we are
> moving to a UNIX format.   I do not disagree.   I think it is a good
> move.   MWC  keeps time in UNIX format.   It is not my intention to
> propose a method to anyone.  Obviously I succeeded in muddying the
> conversation.   I agree with you, Guido.   The kernel should keep
> UTC and conversions are controlled in the application.   TOS, and RTC
> should not be primary kernel activities, but should keep house in
> their own way.   It may require a kernel level time call in TOS mode.
> That is not too expensive is it?   I do not suggest that time be passed
> back and forth.  But provision should be made for applications and
> those of us that are not running minix or e2fs.   The ansi definition
> of localtime is a conversion from (32 bit time) to TOS mode.  MWC does
> it,  LATTICE does it,  (educate fleas.....

Just to make it clear: What you propose here is implemented in the kernel
ever since the new time model was introduced.

To summarize the status quo: The user has the choice, you can run your
clock in UTC or in localtime, you just have to inform the kernel (with
tzinit).  That means, that nobody is forced to use UTC.  In fact, most
MiNT users despite my recommendations, prefer to use localtime and since
the time functions basically work, it can't be that bad after all.

If the kernel has been properly informed about both the timezone and the
clock mode used (both tasks are fulfilled by tzinit) it maintains two
system dates: One is in UTC, the other in localtime.  The kernel always
reads the time from the RTC.  In UTC clock mode it corrects the RTC time
to calculate localtime, in localtime clock mode it corrects the RTC to
calculate UTC.  This is indeed simple, and not very expensive.  It is
getting expensive when these timestamps have to be converted the
broken-down GEMDOS format but that doesn't depend on your clockmode.

Joska, you are not forced to use UTC and in both clock modes all your
timestamps should be correct on all filesystems.  The correctness of the
timestamps is neither a question of the OS you're currently running nor of
the clock mode you use in MiNT.  If you run UTC, the FATFS is still able
to retrieve the current time in local time and can write the timestamp
accordingly.  Under Magic you will see the same timestamp.

The real problem is not the kernel, the real problem is the file system.
File systems that store timestamps in local time instead of UTC are
necessarily unreliable in this respect.  Make a simple experiment: During
one year create exactly one file per hour on a FAT filesystem.  The next
year, read all of these timestamps and check them with your records.  No
matter when you do that, about half of the timestamps will be bogus.  If
you read the timestamps in winter, all the "summer timestamps" will be
wrong.  If you read them in summer, all the "winter timestamps" will be
wrong.

The reason is simple: The kernel may or may not know by how much UTC and
local time differ /now/ but it has no idea about the offset that was in
use when creating the timestamp.  OK, you could improve that system by
storing the offset in an extra field in the filesystem structures.  But
then you can just as well use UTC (like modern systems do) and avoid all
these problems.

BTW, the MiNTLib can compensate that shortcoming to a certain extent.
Whereas the kernel (be it MiNT, TOS or Magic) only maintains static
information about the timezone, the MiNTLib has this information
dynamically available.  If it reads a timestamp that is recorded in local
time it will try to figure out which timezone was in use when the stamp
was written.  It will mostly succeed with this, except for one file.  When
you change from summer to winter time you rewind your clock by one hour.
But that means that two files will have exactly the same timestamp.  There
is no way to find out if the file was written /before/ or /after/ you
rewinded the clock.  You may think, fine, if the libc can compensate the
error and you can live with one wrong timestamp, why not stay with local
time?  Because this libc kludge for old filesystems is really expensive.

But again: The timestamps have nothing to do with UTC or localtime clock
mode.  The kernel has both variants of the system time available and it
simply has to pick the correct one.  If you run UTC you have the chance to
let your system alone and forget about manually setting the clock when you
change from summer to winter time.  It is also a must if you want your
cron daemon to work correctly when the change takes place.  If you prefer
to run in local time you will have problems with cron, you have to change
the clock manually but the advantage is that the system clock will display
the correct time if you boot into TOS or Magic.

I will try to fix the remaining problems with that mechanism and I hope
everybody will be happy again then.  But what about that annoying reboot?
Remember that the kernel has only static timezone information and that is
what makes the reboot (resp. the call to tzinit) necessary.  At first
glance you may think that a well-written cronjob could fix that.  But this
is not only hard to write but also not sufficient.  If you experiment with
your clock and jump not only a minute but a couple of months ahead or
forward you should also be concerned about timezone changes and run tzinit
again.  This could only be handled by a daemon that polls the system clock
in relatively short intervals.  If it detects a leap in the local wall
clock time (be it because you played with the clock or be it due to DST)
it should try to figure out which timezone you are in now and take the
necesary measures (correct the timezone and - if you run localtime -
maybe rewind/forward the RTC).  If you analyze the problem more severely
you will however see that this can only work bomb-proof if the kernel runs
in UTC.  In local time, if you set your clock to 2.30 am of exactly the
day when you switch back from summer to winter time this date is
ambiguous.  That daemon could only guess which date you actually meant.
But this would only be a minor problem compared to the real one: In
localtime clock mode the daemon could indeed never be sure what the time
really is:  If a DST change has taken place recently, how could the daemon
know if it has already reported the change to the RTC?  Record the
information in a file, ok.  But what if you set the RTC yourself behind
the daemon's back, for example in TOS or in Magic?  No way, for UTC mode a
daemon could work but in localtime mode you will always need
user interaction à la Windows "The system clock has been changed due to
DST. Correct?"  Anyway, does anybody really care about these two extra
reboots per year?

Ciao

Guido
-- 
http://stud.uni-sb.de/~gufl0000/
Send your spam to president@whitehouse.gov and your replies to
mailto:guido at freemint dot de