Date: Tue, 19 Feb 2008 00:41:31 -0800 From: Tim Kientzle <kientzle@freebsd.org> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/lib/libarchive archive_read_support_format_iso9660.c Message-ID: <47BA963B.2060704@freebsd.org> In-Reply-To: <20080219071953.GP64299@server.vk2pj.dyndns.org> References: <200802190602.m1J622Fe079227@repoman.freebsd.org> <20080219071953.GP64299@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy wrote: > On Tue, Feb 19, 2008 at 06:02:02AM +0000, Tim Kientzle wrote: > >> Without that, I >> don't see a really good alternative to just giving up and converting to >> localtime with mktime(). > > mktime() and timegm() basically use successive approximation (binary > search) with localtime() and gmtime() - so you can fairly easily > create your own timegm(). I'll probably do this soon. I thought I had some useful workarounds, but each one has broken down on some system or another. > If you have a normalised date, I have a direct formula to go from > year/month/day to number of days past some epoch ... I have such code as well, but it has some assumptions that I'm wary of: * ISO C doesn't require that time_t count seconds (POSIX does, so this is probably not a real concern in practice) * None of the standards defines the epoch (if I remember correctly, old Mac OS used a different epoch, so this is not entirely academic). I've also considered trying to measure the local system epoch and then use direct calculation from there, but that's also really messy to get right. The binary search seems the most robust approach; I just haven't had time to research it yet. Cheers, Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47BA963B.2060704>