Re: [Datetime-SIG] A local timezone class
Guido van Rossum <guido@python.org> 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 [2] https://mail.python.org/pipermail/datetime-sig/2015-August/000471.html
On Mon, Aug 31, 2015 at 2:56 AM, Akira Li <4kir4.1i@gmail.com> wrote:
Guido van Rossum <guido@python.org> 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]
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)
participants (2)
-
Akira Li -
Guido van Rossum