Date: Mon, 30 Mar 1998 17:53:04 +0400 From: =?koi8-r?B?4c7E0sXKIP7F0s7P1w==?= <ache@nagual.pp.ru> To: Bruce Evans <bde@zeta.org.au>, helbig@Informatik.BA-Stuttgart.DE Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: bin/6164 Message-ID: <19980330175304.22851@nagual.pp.ru> In-Reply-To: <199803301316.XAA29255@godzilla.zeta.org.au>; from bde@zeta.org.au on Mon, Mar 30, 1998 at 11:16:08PM %2B1000 References: <199803301316.XAA29255@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 30, 1998 at 11:16:08PM +1000, Bruce Evans wrote: > 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 What do you think about simutaneous increasing local and utc times until mktime() stops failing? What we need to get is new offset and 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). -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ MTH/SH/HE S-- W-- N+ PEC>+ D A a++ C G>+ QH+(++) 666+>++ Y 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?19980330175304.22851>