[Zope3-dev] RE: [Python-Dev] Holes in time

[Tim Peters]

[M.-A. Lemburg]
> Why don't you take a look at how this is done in mxDateTime ?
> It has support for the C lib API timegm() (present in many C libs)
> and includes a work-around which works for most cases; even close
> to the DST switch time.
>
> BTW, you should also watch out for broken mktime() implementations
> and whether the C lib support leap seconds or not. That has bitten
> me a few times too.

I think there's a relevant difference in datetime:  it makes almost no use
of timestamps.  There is no datetime method that returns a timestamp, for
example.  All we've got are "backward compatability" constructors that will
build a datetime object from a timestamp, if you insist <wink>.  Those use
the platform localtime() and gmtime() functions, and inherit whatever
limitations and problems the C libraries have.  Eek -- that reminds me, I
should add code to clamp out tm_sec values of 60 and 61

The broken-out year, month, etc, struct tm members aren't combined again
internally either, as dates and times in this module are stored with
distinct year, month, etc fields.

It's not clear what you mean by "broken mktime() implementations", but the
implementation of datetime never calls the platform mktime().  The test
suite does, though.