cvs commit: src/lib/libarchive archive_read_support_format_iso9660.c

[M. Warner Losh]

In message: <47BA963B.2060704 at freebsd.org>
            Tim Kientzle <kientzle at FreeBSD.org> writes:
: 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)

time_t is defined in 7.23.3.5.2 to be:
       [#2] The time function determines the current calendar time.
       The encoding of the value is unspecified.

so time_t can be anything, really, and still conform to the ANSI-C
standard.  It must also be an arithmetic type.  But it could return
the number of days since Julius Caesar assumed the thrown so long as
difftime() returns the number of seconds.  POSIX is more demanding
here and, despite its many flaws, is better.

: * None of the standards defines the epoch (if I remember
:    correctly, old Mac OS used a different epoch, so this is
:    not entirely academic).

POSIX defines the epoch to be Jan 1, 1970, which effectively defines
it for everybody.

: 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.

localtime suffers from too many discontinuities to be 'easy' to
compute.

Warner