Re: [MiNT] timezone change

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

On Mon, Mar 27, 2000 at 10:08:53AM +0300, Martin-Éric Racine wrote:
> On 2000-3-27, Guido Flohr <gufl0000@stud.uni-sb.de> wrote:
> 
> > > Here, cron executed its activities 1 hour earlier that scheduled,
> > > but the system did not change its clock last night.  MINT.CNF has
> > > 
> > > setenv MINT_CLOCKMODE local
> > > setenv TZ EET-2EEST,M3.5.0,M10.5.0
> > 
> > You should not use localtime, things go much better in UTC.  
> 
> Anbd then my RTC and files show a time that has nothing to do
> with what my wristwatch says.... no thanks.

The environment variable MINT_CLOCKMODE is not evaluated, neither by the
kernel nor by tzinit.  Run "tzinit --localtime" instead.

> > You should also not set TZ if you have the timezone database
> > installed.
> 
> Too many old apps that have not been re-ported depend on the
> environment string.  Even new ones do.  Bash, for instance,
> doesn't like it if it cannot figure out its timezone when it 
> is started in a secondary level shell.

Proof?

> > Anyway, even in UTC, you have to reboot or run tzinit again
> > to inform the kernel about the timezone change.
> 
> What's the point of having _any_ timezone functions at all if the
> kernel won't update itself.  Might as well run Windows...

Read below.

> > The reboot wouldn't be necessary if we didn't have to provide
> > the compatibility functions that deal with localtime (because
> > the kernel simple wouldn't need to know about the timezone).
> 
> Real people live in a specific time zone, not in UTC, thank you.
> Anyhow, seeing that other OSes change time on their own without
> a reboot, sounds like UTC stubornness on your part.  Shame.

Shame? On me? You need little fantasy to figure out what I think of you.
You're both impertinant and ignorant!

A real Unix doesn't have these problems because a real Unix does exactly
what you consider to be stupid:  The OS simply ignores that real people
live in a specific time zone, not in UTC.  It leaves the problem of
converting the system time to the wall clock time the user wants to see to
the application software because that is the only reasonable way to handle
the problem.

Under MiNT you can do the same: Set your real time clock (RTC) in UTC and
use only recent software that uses the new API.  Last Sunday the output of
/usr/bin/date switched from 01:59:59 to 03:00:00, no need to reboot.

All problems have the same reason: Unlike a real Unix system the MiNT
kernel cannot ignore local time altogether: There are people that want to
run other OSes and we therefore need some kludges to make the MiNT kernel
also run in local time.  More important, there is old software that uses
the old API and that API by definition handles dates in local time.

Therefore there must be a way to tell the kernel about the difference of
local time and UTC (no matter if the kernel actually runs in UTC or in
localtime).  And that's the function that tzinit fulfills.  In fact there
is no need for a reboot, you just have to call tzinit with the right
parameters when the timezone changes.  A reboot is the easiest way to do
that.

Besides, there are known problems in the kernel when you change the system
time.  This is another reason why it is recommended to reboot after the
timezone changes.  This is a bug and I will look after it the next time
that I do some work on the kernel.

However, even commercial OSes have problems with the system time (and
that's why you need superuser privileges to change the system time).
HP-SUX 10.20 completely freezes if you turn the clock backwards.  Windows
95, when up during the change from summer to winter time will keep on
setting back the clock by one hour at three o'clock until you reboot and
change the time manually.  I also had problems on my Linux box running a
2.0.37 kernel.

What are the alternatives? Switch back to local time altogether? This
_must_ lead to wrong results.  Boot into plain TOS, set your system time
to Sunday, March 26, 01:59:59 (northern hemisphere).  Half an hour later
the system will happily display a time of 02:30:00.  This is an illegal
time that does not exist (and /usr/bin/date will tell you that provided
that you haven't set $TZ).  Even worse is that TOS will write time
filestamps with that illegal date.  Is that what you call reasonable?

Another big drawback: Both Minix and Ext2 record their timestamps in UTC.
Before the UTC changes in the kernel, filesystems simply ignored that fact
and wrote timestamps in local time because they had no way to find out
what the time in UTC was.  This will lead to wrong timestamps on
exchangable media when you exchange them across platforms.  Not to think
about file systems that are shared across a network.

And if you move from Canada to Finland? All your timestamps will be wrong
after you have moved.

And when the change from summer to winter time or vice versa takes place?
You have to adjust your system clock.

And, we have had that several times, the "main" programming language used
for MiNT is C and the C standard requires that dates are internally
represented in UTC, not in local time.  Converting UTC to local time and
vice versa is quite expensive (have a look at the source files of the
timezone database to get an idea of that).  Therefore using local time or
even worse, the non-standard time representation of GEMDOS imposes an
incredible performance penalty.

The existing problems are caused by the compatibility restrictions, not by
the people that provide you with free software and patiently reply to your
attacks over and over again.

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