The author provides this example to illustrate inconsistent handling of non-existent datetimes: # This time doesn't exist on this date
d = datetime(2023, 3, 26, 2, 30, tzinfo=paris)
# No timestamp exists, so it just makes one up
t = d.timestamp()
datetime.fromtimestamp(t) == d # False
Criticisms:1) The example would fail just as well for any datetime with given tzinfo. Because fromtimestamp returns native datetimes. 2) The timestamp isn't just "made up". Its behaviour is clearly documented in PEP 495, as linked by the author [0]. In this case it consistently corresponds to datetime(2023, 3, 26, 3, 30, tzinfo=paris). [0] https://peps.python.org/pep-0495/ Finally if we disallow creating non-existent datetimes in the proposed library, how do we represent the 2am in "clock changes forwards at 2am"? Use 3am? There are tradeoffs. |
1) You're absolutely right, I'll fix this mistake in the example.
2) "Made up" was perhaps stirring the pot too much ;), but the fact remains that a timestamp is created when one essentially doesn't exist. That this is meticulously documented in PEP495 doesn't change this fact.
Note that PEP495 also explicitly describes some of the other pitfalls. Documenting a 'suprise' is not the same as eliminating it.
> Finally if we disallow creating non-existent datetimes in the proposed library, how do we represent the 2am in "clock changes forwards at 2am"? Use 3am? There are tradeoffs.
Indeed, there are always tradeoffs. Often, only time can tell what was the 'least bad' decision. It is telling though that modern datetime libraries (Noda Time, Chrono, Temporal) in other languages choose to not represent these 'missing' local times.