Date: Fri, 19 Jan 2007 10:45:42 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: peterjeremy@optushome.com.au Cc: cvs-src@FreeBSD.ORG, src-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/stdtime localtime.c Message-ID: <20070119.104542.-1631527280.imp@bsdimp.com> In-Reply-To: <20070119093229.GB860@turion.vk2pj.dyndns.org> References: <200701190116.l0J1GZcD021864@repoman.freebsd.org> <20070119093229.GB860@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20070119093229.GB860@turion.vk2pj.dyndns.org>
Peter Jeremy <peterjeremy@optushome.com.au> writes:
: On Fri, 2007-Jan-19 01:16:35 +0000, Warner Losh wrote:
: >imp 2007-01-19 01:16:35 UTC
: >
: > FreeBSD src repository
: >
: > Modified files:
: > lib/libc/stdtime localtime.c
: > Log:
: > On FreeBSD/arm, any value > 50 bits will result in a rediculously huge
: > number being returned for mktime and timegm calls.
:
: Actually, I have some code that can convert a UTC struct tm into a
: time_t without any loops[1]. Converting localtime would need a couple
: of probes to handle DST. This should be far more efficient than a
: binary search. Is there any interest in this?
:
: [1] The date to day number core started as a FORTRAN one-liner but I
: can't find the source. I've written C and perl versions and
: exhaustively tested them.
Part of the problem is that timegm and mktime have to work with
non-normalized struct tm's. The code we have is standards conforming
(or very close). If there were some kind of regression tests to prove
the new code worked, then I'd love to see the current code replaced.
It is somewhat twisty...
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070119.104542.-1631527280.imp>