Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 31 Mar 1998 00:16:49 +0200 (MET DST)
From:      Wolfgang Helbig <helbig@Informatik.BA-Stuttgart.DE>
To:        bde@zeta.org.au (Bruce Evans)
Cc:        ache@FreeBSD.ORG, helbig@Informatik.BA-Stuttgart.DE, freebsd-bugs@FreeBSD.ORG
Subject:   Re: bin/6164
Message-ID:  <199803302216.AAA08860@rvc1.informatik.ba-stuttgart.de>
In-Reply-To: <199803301316.XAA29255@godzilla.zeta.org.au> from Bruce Evans at "Mar 30, 98 11:16:08 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
> >Hmm. The reason for this warning message (``non existent UCT time'')
> >is an erraneous use of mktime(3): mktime(3) *always* assumes
> >that the passed tm structure (utc) holds *local* time, even if the
> >parameter is filled by gmtime(3). 
> >At March 29th 4:01 CEST gmtime() put 2:01 into utc, which is correct.
> >Then mktime(3) assumes March 29th 2:01 *local* time which does not exist.
> 
> Isn't that the point of using local time?  The purpose of `adjkerntz -a'

I don't argue using local time or mktime() assuming local time.
I just don't think it's a good idea to use mktime() with an argument
that is supposed to hold utc time in order to calculate the
offset from local time to utc.

Using tm_gmtoff looks better to me and does not need this sleep mode.

> is to adjust the RTC to local time when DST changes.  The adjustment
> can't be done if it would give a nonexistent time or an ambiguous time.
> mktime() happens to handle nonexistent times in a convenient way (by
> failing; it's not clear what else it could do).  I think there are more
> problems with ambiguous times when DST starts, since mktime() doesn't
> fail then.

The current version which uses mktime() is broken in this respect.
Consider what happened March 29th when daylight saving made the
local clock jump from 1:59 CET to 3:00 CEST, and the utc-offset
from -3600s to -7200s.

>From 3:01 to 3:59 adjkerntz -a thought -3600 is the correct offset,
(at least that's what it writes in machdep.adjkerntz) and adjkerntz -i does
bogusly *not* update the RTC when started at 1:55 CET and terminated
(kill -term) at 3:10 CEST. This is an error.

>From 4:01 to 4:59 adjkerntz -a thinks it suddenly has to fight some
non existant utc. But the localtime (4:01) perfectly exists and the
corresponding utc (2:01) also perfectly exists. Only the localtime 2:01
does not exist. But this fact certainly is not important for the algorithm
used by adjkerntz--as far as I can grasp it. Sure, mktime() happens
to return (-1) but this happens to be of no relevance at all to the
task at adjkerntz is trying to solve.

>From 5:00 adjkerntz -a and adjkerntz -j finally work as expected.

Anyway, with my patch applied, adjkerntz works as before (including
the bug occuring from 3:01 to 3:59 two nights ago) but does not 
repeat the bug from 4:01 to 4:59. Instead it correctly computes
the offset and adjusts the RTC if started with -i before daylight saving
switch and terminated after 4:01.

The other bug (3:01-3:59) is still open.

Wolfgang

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803302216.AAA08860>