[Datetime-SIG] IANA TZ database statistics
alexander.belopolsky at gmail.com
Thu Sep 24 17:26:34 CEST 2015
On Thu, Sep 24, 2015 at 1:37 AM, Tim Peters <tim.peters at gmail.com> wrote:
> I also agree figuring out the system zone's rules is a puzzle using
> POSIX. Note that Gustavo gave up on trying to use mktime() in
> dateutil's tzlocal class.
I think he was bitten by the flaky behavior of mktime() when tm_isdst is
passed as -1. I intend calling mktime twice with tm_isdst=0 and tm_isdst=1
and detect fold/gap by what mktime that does to the tm structure. If we
discover that some systems misbehave even in tm_isdst>=0 cases, we can roll
out our own mktime() that probes localtime() multiple times.
> You could say time.timezone and
> time.altzone define the only two (or one, if time.daylight is 0)
> possible total UTC offsets, and assume that's always been, and always
> will be, the case.
Linux (glibc) updates timezone, altzone and tzname whenever localtime() is
called. I think this is a horrible hack, but it does not seem to be in
violation of POSIX.
> But I don't think even `altzone` is actually
> required by POSIX - it's of little help :-(
I don't want to rely on any of these variables. For offsets, I would just
compute the timestamp on the output of localtime_r (the reentrant version
does not mess with globals) and compare that to the input timestamp. For
tzname, I would use strftime("%Z") which seems to be rather portable. Of
course, on platforms where localtime and mktime fill in tm_gmtoff and
tm_zone, I can just use those.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Datetime-SIG