Re: [MiNT] tzinit bug

[Martin-Eric Racine <q-funk@pp.fishpool.com>]

> > > > INIT refuses to work in local time.  After RC.BOOT, the date is 
> > > > displayed as GMT (eg: correct GEMDOS time, but GMT as timezone).
> > > 
> > > What does "date" say, after you logged in?
> > 
> > Fri Jan 22 18:08:46 GMT 1999
> > 38463568 bytes (37562K) in 41 blocks free, largest free block: 34849392
> > (34032K)
> > uid=0(root) gid=0(wheel) TERM=tw100 UMASK=026
> > rakastaja:/e/home/root$ echo $MINT_CLOCKMODE
> > local
> > rakastaja:/e/home/root$ echo $TZ
> > EET+2DST,3.5.0,10.5.0
> > rakastaja:/e/home/root$ tzinit
> > tzinit: setting system timezone information.
> > Timezone in use: EET.
> > Offset to Greenwich Mean Time: 120 minutes.
> 
> This should be -120 minutes for you.
> 	TZ=EET-2DST,...

OK... I changed this. 
It still displays itself as being GMT, even though TZINIT's 
message says timezone is EET.  

> > Daylight savings time in use: no.
> > Kernel clock ticks in local time..
> 
> This has no advantage for you.

Yes it has.  

We all have a few old programs that refuse to work under multi-tasking
but provide certain functions not available on newer software.

Working in localtime means files written in SingleTOS will have a time
stamp that remains consistant with work done under MiNT.  

> It is possible that the timestamp problems you report also result
> from your bogus environment.  I've never experienced any problems
> with N.AES running with UTC-kernel.

Maybe the incorrect localtime support is the result of bogus programming.
I've never experienced timezone problems before TZINIT was included in the
distribution.

For instance, it appears that even though TZINIT reads its config
environment (and reports I am in EET), 'date' always returns the 
time as being GMT anyways (wehter MINT_CLOCKMODE is local or UTC,
'date' always says "day month date time GMT year" instead of the
expected "day month date time TZ year").

Similarly, MiNT's clock is always offset by X minutes (as specified
in the TZ environment) even if I specifically request "local" time.

Proof:

Clocky (the cornerclock/mouseaccelerator by Petr Stehlik) shows
a certain time during AUTO-folder process (which seems to come
straight from BIOS time).  

After the kernel and N.AES have booted, 'date' and X-Control
(which seems to indicate GEMDOS) are 2 hours ahead of the time 
displayed by Clocky (which matches the time showed in SingleTOS)

What this tells me is, TZINIT is not synchronized with the RTC,
even though I specify MINT_CLOCKMODE=local.

So....

Can you please fix it and stop assuming everyone else has got a
bogus setup, just because some people don't use UTC like you do?

Thank you.

PS: I'm not trying to undermine your programming effort.  However,
    I think "local" support ought to be fixed.

    Basically, MINT_CLOCKMODE=local should mean "date is whatever
    the RTC tells me it is, but it happens to be located in TZ
    "blah" which is "x" minutes before/after GMT".

    After this is fixed and bullet proof, I even advocate that TZINIT 
    be integrated into the kernel itself, introducing new MINT.CNF
    keywords TZ=(timezone) and CLOCK_MODE=(local or UTC).

    So, please consider this as a thorough bug report (with a few
    emotionally charged worries about incorrect timestamping), not
    as a flame.  ;-)

----------------------------------------------------------------
  Martin-Eric Racine * http://www.pp.fishpool.com/~q-funk/M-E/
  The Atari TT030 Homepage * http://members.tripod.com/~TT030/
----------------------------------------------------------------