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

Thu Aug 6 21:11:24 CEST 2015

On Thu, Aug 6, 2015 at 11:29 AM, Tim Peters <tim.peters at gmail.com> wrote:

> TAI has more than one "moving piece".  Because _all_ the pieces are
> important to the relative handful of people who need TAI, it's highly
> misleading to call something "TAI" unless it implements all the
> pieces.
>
> Provided you view naive datetimes as expressing times in TAI calendar
> notation, then, yes, Python's calendar notation and classic arithmetic
> implement those parts of TAI precisely.
>
> But there's no builtin support for any other piece needed to use TAI:
>

Fair enough.

- There's no way to ask "what time is it now?" and get a TAI result
> (unless you're on one of the rare rumored Linux variants configured to
> use TAI for the system clock), neither in TAI seconds-since-the-epoch
> notation nor in TAI calendar notation.
>

uhm, yeah, we'd need to handle leap-seconds for that :-)

> - There's no direct way to ask how a datetime expressed in TAI
> calendar notation is expressed as TAI seconds-since-the-epoch
> notation.  This is easy to write a function for, though (subtract a
> naive datetime expressing the start of the TAI epoch in TAI calendar
> notation).  Ditto in the other direction.
>

kind of my point -- you can't do that with python datetime and "real" UTC...

- There's no way to use the current timezone implementation to convert
> TAI to or from any other time scheme.
>

Ah, yes -- again my point -- I don't think we want to preempt this being
possible in the future (probably with an third party lib)

> 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.
>
> Even worse, businesses generally want _not_ to see actual elapsed
> time.

right -- even stronger point.

> > time. And for that, python's datetime is very, very useful. And
> > primarily because it does a good job with 'strict' timedeltas.
>
> In the language we seem to have settled on, timedelta does "classic
> arithmetic" now, and how it _would_ work if it _did_ account for
> things like DST transitions is called "strict" or "timeline"
> arithmetic.
>

right -- forgot to sprinkle "naive" liberally around this post....

> I don't see how that could be a primary use now, since Python's
> datetime arithmetic now doesn't do "proper timespan computation" (as I
> believe you mean it) in any time zone defined as an offset (including
> 0) from real-life UTC.
>

indeed it doesn't -- but that is indeed a primary use now -- but only with
naive datetimes -- we have to handle timezones independently. Fortunately,
at least in the data I work with, the datetime is expressed in ISO 8601
text form, which lets you specify an offset, but not a politically drive,
changes who knows when time zone. So "switch to UTC, use naive datetimes",
works fine.

But I'm interested in all this because it would be very nice to be abel to
properly handle full time zone support.

You can't do it using POSIX seconds-from-the-epoch timestamps either
> (not directly; you would need additional code to account for leap
> second adjustments across the span of interest).

Uhhm, but it seems I've been told over and over again in this thread that I
shouldn't want leap seconds, no one cares about them, and python will never
support them?!??!?

So can we just leave it at:

"There are no plans for python to support leap seconds, and it is also not
a motivating factor in current work to make it possible in the future."

When and if (big if) anyone want to try to support leap seconds in the
future, we can discuss whether it's possible or a good idea then.

I like the idea, but I like a lot of ideas, and for now, I'm happy enough
to say that anyone passing me data in a dumb-ass epoch may get their
results 26 seconds or so off.

> (And a lot of the data I've seen is based on poor choices of epoch,
> > unfortunately)
>
> Social problem:  nag them ;-)

sure -- but we need to deal with what we need to deal with -- heck if we
could drive use cases with software developers needs, we sure as heck
wouldn't have DST!

As long as it's a 26 or so seconds problem, I'm fine. On the other hand, we
just got a data set encode to a "I have no idea why" epoch before 1970,
which breaks all our old C code that uses unsigned integers since 1970. So
we have to translate that to a better epoch first (using python's datetime,
natch).

I just hope some of it finds some actual use ;-)

at least some will...

> Have you read this
> yet?  It explains a lot.
>
>     https://en.wikipedia.org/wiki/Unix_time

thanks for the link -- I _think_ I knew all that, but good to have it one
place.

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150806/326d21ac/attachment-0001.html>