Stuart Bishop <[email protected]> writes: > On 25 August 2015 at 13:39, Akira Li <[email protected]> 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. _______________________________________________ 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/
