[Carl] > ... > So PEP 495 is already breaking the design of datetime, that tz-annotated > datetimes operate internally on a naive time model. It _has_ to break > that design, because it must introduce times that don't exist in that > model. But it's choosing to change that design piecemeal and > inconsistently instead of thoroughly and consistently.
It was never consistent for all possible uses: as has been gone over many times before, an aware datetime _can_ be viewed as being an instant in "naive time", _or_ as an instant in civil time. That's solely in the programmer's head. They may even view a single datetime in both ways in different lines of code (I know I do - indeed, that's the norm for me). Python has no way to know which the programmer has in mind; there is no way to _spell_ "I mean naive time" versus "I mean civil time" for aware datetimes. I believe Guido thinks that's "a feature". I think it's just "good enough" ;-) Since the concept of "timezone conversion" doesn't exist in naive time, a programmer asking for a timezone conversion can only have "instant in civil time" in mind at the instant they ask for that conversion (or invoke any other tzinfo method). We're aiming to accommodate that use, in a design that never put a wall between the concepts from the start. It's not ideal, but that's not really news ;-) _______________________________________________ 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/
