[Datetime-SIG] IANA TZ database statistics

[Alexander Belopolsky]

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...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150924/a8d05bf7/attachment.html>