<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 24, 2015 at 1:37 AM, Tim Peters <span dir="ltr"><<a href="mailto:tim.peters@gmail.com" target="_blank">tim.peters@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":2ey" class="" style="overflow:hidden">I also agree figuring out the system zone's rules is a puzzle using<br>
POSIX.  Note that Gustavo gave up on trying to use mktime() in<br>
dateutil's tzlocal class.</div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":2ey" class="" style="overflow:hidden">  You could say time.timezone and<br>
time.altzone define the only two (or one, if time.daylight is 0)<br>
possible total UTC offsets, and assume that's always been, and always<br>
will be, the case.</div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":2ey" class="" style="overflow:hidden">  But I don't think even `altzone` is actually<br>
required by POSIX - it's of little help :-(</div></blockquote></div><br>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.</div></div>