[Datetime-SIG] pytz vs. PEP 495 Was: PEP-431/495

ISAAC J SCHWABACHER ischwabacher at wisc.edu
Mon Aug 24 23:46:56 CEST 2015

> > [ijs]
> >>>> I *really* hope the answer to this one is, "don't do that".
> >
> > [Alexander Belopolsky]
> >>> That's not an option because people already *do* [1] that and they won't stop.
> >>> Neither they will stop using datetime.combine() [2] or datetime.replace() [3]
> >>> or tolerate if those methods start raising exceptions.
> >
> > [Ethan Furman]
> >> If the default is True (or False), then this won't be a problem.  It will only
> >>  be None when explicitly asked for.
> >>
> >> `time` can just store the flag, and when it is combined with a date the flag
> >>  should be checked and if None and the resulting datetime doesn't exist or is
> >>  ambiguous an exception can be raised.
> >
> > A time with a non-constant-offset tzinfo is always ambiguous, and can have an
> >  arbitrary number of possible offsets. There are several time zones with at least
> >  three possible offsets for a given time in the last 10 years. How on earth do
> >  you define the meaning of a time with a non-constant tzinfo attached? Or does it
> >  only mean something when it's recombined with a date?
> I hope the only way I would use a plain time is for today (whichever day 'today' happens to be), in which case having a tzinfo is still helpful for knowing what time it is somewhere else.  Which is
> still a buggy proposition on days involving time switches.

Sounds like "don't do that" to me.


More information about the Datetime-SIG mailing list