[Datetime-SIG] PEP-431/495

Akira Li 4kir4.1i at gmail.com
Tue Aug 25 13:44:12 CEST 2015


Stuart Bishop <stuart at stuartbishop.net> writes:

> On 25 August 2015 at 13:39, Akira Li <4kir4.1i at gmail.com> wrote:
>
>> As far as I know utc -> local timezone *conversions* do not work during
>> DST transitions in dateutil [1] while pytz manages just fine.
>>
>> Let's not do, whatever dateutil does here. It would be a regression.
>
> dateutils does not work at the moment. With the addition of the new
> flag proposed by PEP-495 it should be a simple update to make
> dateutils work. Similarly, depending on the semantics of the updated
> datetime constructors it may be possible to drop pytz' localize method
> and have it work better.

It is not clear why one need a disambiguation flag if there is no
ambiguity in utc -> local timezone conversions but it is great that
PEP-495 might help fix the dateutil bug [1]

[1] https://github.com/dateutil/dateutil/issues/112

Should it also help fix datetime.now(tz.tzlocal()) [2] bug -- getting the
current time in the local timezone as an aware datetime object?

[2] https://github.com/dateutil/dateutil/issues/57

note: stdlib variant datetime.now(timezone.utc).astimezone() may fail if it
uses time.timezone, time.tzname internally [3,4,5] when tm_gmtoff
tm_zone are not available on a given platform.

[3] http://bugs.python.org/issue1647654
[4] http://bugs.python.org/issue22752
[5] http://bugs.python.org/issue22798

pytz variant datetime.now(tzlocal.get_localzone()) works even during DST
transitions.

If PEP-495 implies that dateutil type of timezone implementation might
be adapted in stdlib; it might be worth mentioning to what types of bugs
it leads to.


More information about the Datetime-SIG mailing list