[Python-Dev] datetime nanosecond support (original) (raw)
Christian Heimes lists at cheimes.de
Thu Jul 26 15:00:52 CEST 2012
- Previous message: [Python-Dev] datetime nanosecond support
- Next message: [Python-Dev] datetime nanosecond support. list of proposals
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Am 25.07.2012 16:38, schrieb Guido van Rossum:
Beware, people requesting dates BC rarely know what they are asking for. (E.g. Jesus wasn't born on 12/25/0001.) The calendrical ambiguities are such that representing dates that far in the past is better left to a specialized class. Read the original discussions about the datetime type; it loses meaning for dates long ago even if it can represent them, but the choice was made to ignore these and to offer a uniform abstraction for 1 <= year <= 9999.
For starters. Calendars have more subtle edge cases, for example TAI has a 10 second offset from UTC plus 15 leap seconds. Or the leap year errors in Julian calendar that are handled differently in proleptic Julian calendar which has unsystematic leap years between 45 BC and 4 AD. The rotation velocity of the Earth isn't constant, too. It's a major PITB!
TBH I'm more worried about years >= 10000. :-)
Why life in the past? The future is ... err the future! :)
Christian
- Previous message: [Python-Dev] datetime nanosecond support
- Next message: [Python-Dev] datetime nanosecond support. list of proposals
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]