From owner-freebsd-bugs  Mon Mar 30 06:11:02 1998
Return-Path: <owner-freebsd-bugs@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id GAA07453
          for freebsd-bugs-outgoing; Mon, 30 Mar 1998 06:11:02 -0800 (PST)
          (envelope-from owner-freebsd-bugs@FreeBSD.ORG)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA07447
          for <freebsd-bugs@FreeBSD.ORG>; Mon, 30 Mar 1998 06:10:57 -0800 (PST)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id AAA31223;
	Tue, 31 Mar 1998 00:08:54 +1000
Date: Tue, 31 Mar 1998 00:08:54 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199803301408.AAA31223@godzilla.zeta.org.au>
To: ache@nagual.pp.ru, bde@zeta.org.au, helbig@Informatik.BA-Stuttgart.DE
Subject: Re: bin/6164
Cc: freebsd-bugs@FreeBSD.ORG
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

>What do you think about simutaneous increasing local and utc times
>until mktime() stops failing? What we need to get is new offset and

Isn't that what adjkerntz -as does?

>it will remains the same even after 6 hours beyond zone change.
>I.e. I suggest not mktime(local) - mktime(utc) but 
>mktime(local + 6h) - mktime(utc + 6h). 

Don't you have to do both to see if there is no change?  It would
be fairly easy to calculate the time to sleep before a change can
be made (6 months in some cases :-), but there isn't much point
since waking up every 30 minutes is efficient enough (at least if
it is only for a few hours).

Bruce

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