[Python-Dev] Status on PEP-431 Timezones

Łukasz Rekucki lrekucki at gmail.com
Tue Jul 28 10:25:28 CEST 2015


As it's very hard to keep up with the pace of this thread, instead of
addressing any particular response I would like to add some
(hopefully) useful context.

While Java was historically known for the worst date/time handling
ever (e.g. months starting with 0), in Java 8 a new module was added
named javax.time[1]; It contains (amongst others) the following

LocalTime (= datetime.time)
LocalDate (= datetime.date)
LocalDateTime (= datetime.datetime without tzinfo)
OffsetDateTime (= datetime.datetime + datetime.timezone)
ZonedDateTime (AFAIU equivalent to how Lenart wants the
datetime.datetime + IANA timezone to work)
Instant (a calendar independent representation of a point in time using UTC-SLS)

Duration (= datetime.timedelta)
Period (e.g. 1 year, 2 months and 3 days - no real counterpart in Python)

(I'm not sure which class would be equivalent to what Tim describes.)

While having some Java-style boilerplate, this API is both pure and
very practical. Each class serves a bit different purpose and covers
different use cases without ambiguity and implicit assertions.

Maybe instead of trying to decide who is "wrong" and which approach is
"broken", Python just needs a more clear separation between timezone
aware objects and "naive" ones?

[1]: https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html

Best Reagards,
Łukasz Rekucki

More information about the Python-Dev mailing list