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  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 
Should it also help fix datetime.now(tz.tzlocal())  bug -- getting the
current time in the local timezone as an aware datetime object?
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.
pytz variant datetime.now(tzlocal.get_localzone()) works even during DST
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