On Mon, Aug 31, 2015 at 2:56 AM, Akira Li <[email protected]> wrote:
> Guido van Rossum <[email protected]> writes: > > > I've written a simple class that implements a local timezone tzinfo > object, > > deferring to what the time module exposes about the local zone. > > > > https://gist.github.com/gvanrossum/ef201fe313719305c4c7 > > > > There are two variations: one for systems that support tm_gmtoff and > > tm_zone, one for systems without those. > > > > Output of the test program: > > > > BetterLocalTimeZone > > Fri Aug 28 15:50:22 2015 PDT (-0700) > > Wed Feb 24 15:50:22 2016 PST (-0800) > > > > I'm not entirely sure why we didn't add this to the stdlib ages ago. > (Maybe > > out of a sense of perfectionism, since time.localtime() may be wrong for > > dates in the past or future where different DST rules or a different > > standard offset apply? But why would we care, if we're fine with the time > > module's behavior?) > > If tm_gmtoff, tm_zone attributes are not available then time module does > not provide a way to get correct tzname [1]. In particular, > datetime.astimezone() may fail to return a correct tzname due to that [2] > > [1] http://bugs.python.org/issue22798 That bug report is incomprehensible. You have received feedback about this already. > > [2] > https://mail.python.org/pipermail/datetime-sig/2015-August/000471.html > So is this message. -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
