Re: [MiNT] timezone change

[Guido Flohr <guido@freemint.de>]

Hi,

On Wed, Mar 29, 2000 at 07:31:00PM +0100, Jörg Westheide wrote:
> Hi Guido!
> 
> GF>And Minix and Ext2 wants RTC = UTC.
> Do Minix and Ext2 read their time directly from the RTC?

You should have quoted the the statement that I referred to here. ;-)

> I don't think so, I think they get it from the kernel (else they are
> misdesigned, IMO).
> So they do not require RTC = UTC, they require the kernel to pass the time in
> UTC. That's a big difference

Every application that directly reads the RTC is misdesigned.  Therefore
no application should bother if the kernel prefers to keep the RTC in UTC.

> But that doesn't hinder MiNT from working with UTC. The only thing MiNT has
> to do for that is to convert the time it gets from the RTC to UTC (everytime,
> when the RTC is accessed, but only then).

And that's exactly what happens (I think I have said that several times)
when you run your kernel clock in local mode, you have the choice.

The drawback of a localtime kernel clock is however, that the system clock
will take a leap as soon as you inform the kernel about the timezone in
use.  Jörg's current timezone is CEST-2.  When he boots at six o'clock the
kernel will think at boot time that it is 6:00 UTC.  Then he runs tzinit,
sets the timezone CEST-2 and the kernel realizes that it is really 4:00
UTC.  All timestamps written between system start up and that clock warp
will be wrong.

> GF>Unix UTC timestamps are simply an integer number (the number of
> GF>seconds since Jan 1, 1970, 0:00 UTC). GEMDOS timestamps are broken-
> GF>down (i. e. hour, minute, second, day, month, year are all stored in a
> GF>separate integer value).
> That's right, but the timestamp format is independend from the time base (UTC
> or local time)

Yes, and the main change in the kernel time-keeping model was the
migration from GEMDOS format to Unix format.  The possibility to run the
kernel clock in UTC was a minor change compared to that (since you still
have the chance to run in local time).

> Besides that:
> 
> GF>Add a second to a GEMDOS timestamp:
> In this situation you can asume the GEMDOS time stamp to be valid which
> allows it to reduce the costs significantly by restructuring the code like
> this:

Did you seriously think I would implement it exactly like the pseudo-code
I have given as an example?

I really don't understand that uproar: The current kernel time-keeping
model is fully compatible to GEMDOS.  If you simply run mint.prg from your
auto-folder the kernel will think that it runs in UTC and that the RTC
(real time clock) gives the time in UTC.  The old GEMDOS functions
Tgettime and Tgetdate /and/ the new MiNT function Tgettimeofday will all
return the same.  Ok, this time is really localtime and not UTC but
neither the kernel nor the applications will care because that's exactly
(100 %) the same situation as on a plain TOS or Magic system that don't
care about timezones.

The other extreme is a user that wants maximum Unix compatibility.  On a
Unix system the clock always runs in UTC.  Some OSes that are often run on
micro-computers (like Linux or MiNT) offer kludges to run in localtime in
order to allow the users to run other non-Unix OSes parallely but that is
just a kludge.  The Unix applications on this system will call
Tgettimeofday and will always get the time in UTC like they expect it and
the user will only use filesystems that store their timestamps in UTC.  No
need for any OS component (kernel or drivers) to know about the timezone
the user (NOT the system! A user can log in from the other side of the
earth!) lives in.

You (and the kernel) only has to do extra-work when it comes to a mixture
of GEMDOS and MiNT.  Then the kernel has to know about the current
timezone so that it can serve both needs.  In the recommended UTC
environment you simply tell the kernel the offset UTC<->local so that it
can give applications that want local time the correct values.  In a local
time environment the kernel clock also has to take a leap in order to
compensate for the wrong timezone it assumed before it was informed about
the real offset.  But this is not a weakness of the kernel but of the
local time model in general.

In a mixed environment this clock warp is inevitable: If you run in local
time mode GEMDOS applications (apps that use the old GEMDOS functions) are
preferred since the GEMDOS applications will receive consistent timestamps
before and after the clock leap.  In UTC mode you prefer Unix applications
because the Unix functions will return the same before and after the leap
(and therefore Unix applications reflect reality where UTC is constant and
local time is likely to take leaps).

You have the choice: Don't use tzinit at all or use tzinit and set your
kernel to local time and you can enjoy all the shortcomings of a local
time OS (and run such OSes parallely) or run in UTC, never change your
clock manually, move your computer from one place of the world to another
and still be fit to run your system in a network environment of arbitrary
extensions.

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