[MiNT] Time and again ...

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

Hi all!

There have been some irritations about the kernel time keeping model
lately.  Some remarks:

1) If you are not content with the kernel time model for some reason 
or another, just don't use it!

If you remove all time related stuff from your mint.cnf, especially
if you don't run tzinit, your system will behave exactly the way
it did in the past.

2) The most common reason for problems is a wrong setting for the
$TZ environment variable.  If you use this wrong setting throughout
your configuration files (mint.cnf as well as /etc/rc*) you will
experience various problems, only a few subset of them will really 
be kernel problems.  Most of them are really "ordinary" software
problems. For example, the "date" command will always produce wrong
results if you use a wrong syntax for "$TZ", no matter what kernel
version, no matter what operating system you use.

The "date" command is quite a good test to validate your TZ setting.
Please open a shell and first check your TZ syntax:

	bash$ TZ=FOO-5BAR-6 date

This command will change your TZ environment variable /only/ for the
time the date command will be executed.  The date command will then
report the current date and time for the timezone you specified.  If
there is a syntax error in the TZ variable, "date" will instead ignore
it and report the time in GMT (or maybe UTC).  If such a syntax 
error occurs the tzinit command must fail, too!

If the tzinit command reports at boot time that the timezone in use
is GMT then you almost certainly have a syntax error in $TZ.  

Please read the documentation about the TZ syntax carefully and then
try to find the error.  You are not restricted to the TZ documentation
in the kernel docs; any documentation on the subject will do.  A good
introduction can also be found in the info files for the GNU libc.

3) Please do not interpret too much magic into the tzinit program.  (Have
a look at the sources, even if you are not a programmer.  Where do you
want to put that magic into a mere 20-liner?)

The TZ environment variable is currently the only way to tell any
MiNTlib based program about the timezone you live in.  I have not
invented this technique and I am not responsible that the MiNTlib
currently does not provide more powerful mechanisms (like the
zoneinfo file used in Linux installations).

4) I am not familiar with current MiNTlib implementations of timezone
handlings.  As for patchlevel 46 it was broken!  If the tzinit
program was linked against broken code in the MiNTlib it will
"inherit" these bugs.

Known bugs (of the MiNTlib!) range within:

- Support for the southern hemisphere may be completely broken.
- Start and end time specifications for daylight savings time
  may be ignored or misinterpreted.
- Some syntax features (like specifying a Julian date) may not
  be supported.
- ...

If you find such a bug you have to find some way to work around
it.  Remember:  The /only/ significant output of tzinit is the
line "offset to GMT: xxx minutes".  If you find a setting that
produces the right result for the place you live, you've won.  The
kernel does /not/ interpret the name of your timezone, nor does
it put much stress on the fact if daylight savings time is in use
or not (in fact it merely stores this information as a flag and
passes it to callers that inquire the information).

One simple way to to this is to change your mint.cnf manually
each time DST starts/ends.  For the southern hemisphere you
can also try to simply swap your timezones.  A simple TZ setting
like 

	TZ=FOO-6

will /always/ work. 

5) As far as I can see it, the bugs in the time code of the MiNTlib
are much more important and they should be fixed (resp. the MiNTlib
should be enhanced to support more flexible mechanisms).

As a matter of fact it is no problem to create a replacement for
tzinit which follows a different approach.  The kernel actually only
has to know by how many minutes the local time differs from 
Universal Time Coordinated (UTC) and if the real-time clock provides
a local time or a time in UTC.  If you find a more error-prone
interface to provide this information, go ahead!

6) The kernel keeps up two different clocks:  One is in UTC, one is
in localtime.  Exactly one of them is identical to the hardware
clock (depending on whether you use the UTC or local clock mode).
For the other clock an appropriate offset is added.

This is very simple, and it has proved to work.  There has been
found one (!) reproducable bug concerning this approach which will
be fixed in the next FreeMiNT release (and this bug only affects
people who live in the timezone of Auckland/New Zealand).  All other
bug reports have so far turned out to be either syntax errors or
prove deficiencies which are already described in the kernel
documentation.

I promise that I will have another severe look at the relevant sources in
the near future, maybe I can also provide some enhancements to the
MiNTlib.  It is also thinkable to maintain a list of working TZ settings
for most regions of the world.  I will also give the local mode more
severe testing but please give me some months for that.  I'm currently
very much occupied with another project.

For now:  If you have to use a localmode clock and you think this whole
stuff does not work, just turn it off.  That does not hurt at the moment.
If you run exclusively FreeMiNT, use the UTC clock mode.

Ciao

Guido
-- 
http://stud.uni-sb.de/~gufl0000/
mailto:gufl0000@stud.uni-sb.de

Saliva causes cancer, but only if swallowed
in small amounts over a long period of time.
		-- George Carlin