[Datetime-SIG] Fwd: Calendar vs timespan calculations...

Chris Barker - NOAA Federal chris.barker at noaa.gov
Thu Aug 6 17:11:04 CEST 2015


>  What they can't do with the builtin stuff is get exact
>> duration in SI seconds between two datetimes viewed as representing
>> real-life UTC.
>>
>> Which Chris wants to do.  Endlessly ;-)

Yes, but only back to 1820 ;-)

>> Don't add TAI as an alias.  Only a relative handful of people have
>> ever heard of it.  Among those who both have and care about it, it has
>> a precisely defined meaning which isn't satisfied at all unless they
>> _can_ get elapsed SI seconds by subtracting.  That's a primary use
>> case for TAI.

Doesn't an implementation of the Proleptic Gregorian Calendar with no
leap seconds provide that? e.g. the Python datetime implementation?

M-A s note made this all a bit more clear to me: business use cases
are a lot more concerned with the Calendar than actual elapsed time.
On the other hand, I do scientific applications, and am far more
concerned with accurate elapsed time.

And yes, most code uses an internal time representation in integer
seconds, or the like.

But we still have to deal with input and output in human-friendly
time. And for that, python's datetime is very, very useful. And
primarily because it does a good job with 'strict' timedeltas. In
fact, given that integer units of time are the most natural, the
primary use of python's datetime that I've seen is to convert to-from
a "timespan since an epoch" representation, which requires proper
timespan computation.

(And a lot of the data I've seen is based on poor choices of epoch,
unfortunately)

So my entire point here is that it's great to preserve and enhance
that capability, and leave the door open to future enhancements. And
Alexander's work looks like it's going in the right direction.

Thanks for indulging me -- I, at least, learned a lot.

-Chris


More information about the Datetime-SIG mailing list