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

[M.-A. Lemburg]

On 05.08.2015 22:01, Tim Peters wrote:
> [M.-A. Lemburg <mal at egenix.com>]
>> I think you are mixing up a few things here, or I'm just
>> misunderstanding you, which is just as possible (date/time is
>> full of wonders, so no surprise there :-))
>>
>> If you have a local date/time value which references a day and an time
>> on that day, you can convert this into UTC without caring about
>> leap seconds at all. The reason is that the conversion is done
>> to, again, a date and a time on that day.
> 
> I think almost everyone here does understand all this, although I
> don't believe your last point was explicitly pointed out before.  It's
> worth pointing out!  A time entered as YYMMDD HHMMSS can be viewed as
> specifying an exact real-life UTC time, and so can (within the
> limitations of the system clock) asking "what time is it now?".  For
> most people, that's enough.
> 
> Leap seconds do cause the TAI and UTC Gregorian calenders to drift
> more & more out of synch over time, but, as you say, those so inclined
> can view each new day as starting exactly in synch with real-life UTC
> again.  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 ;-)

Looking at the Earth's irregular rotation and the many factors
influencing it, I wouldn't be too sure about an everlasting
increase in UTC-TAI difference, but you're probably right about
this not changing in our lifetime :-)

These are the fine folks modelling all this:

    http://hpiers.obspm.fr/eop-pc/index.php

(note how the length of a celestial day changes even within each year)

and here's a list of factors that influence the Earth's rotation:

    http://hpiers.obspm.fr/eop-pc/index.php?index=excitation&lang=en

and their direct influence on the UTC-TAI difference:

    http://hpiers.obspm.fr/eop-pc/index.php?index=leapsecond&lang=en

(note how we've managed to slow down the increase in difference
around the year 2000).

Oh, and BTW, these are the result of their latest poll regarding
a redefinition of UTC without leap seconds:

    http://hpiers.obspm.fr/eop-pc/questionnaire/reponse_questionnaire.html

Doesn't look like it's going to change anytime soon :-) I guess we'll
just end up with more advanced notice of new leap second additions.
OTOH, if we do more research into what happened around 2000, we
might even get UTC back in line with TAI. Perhaps we just need
more Internet bubbles bursting ;-)

>> ...
>> Regarding terms: I started with "GMT" in mxDateTime, then
>> added "UTC" as alias, and may well add "TAI" at some point as
>> another alias. For most people, these are all the same, anyway :-)
> 
> 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.  The primary use case for UTC is to approximate UT1
> ("solar time") in a way that doesn't require changing what "a second"
> means. as a duration, at every instant.
> 
>> Purists will loudly disagree, of course, but I have the Zen
>> of Python to my rescue: practicality beats purity.
> 
> So long as you add "Refuse the temptation to add TAI as an alias for UTC" ;-)

Hmm, you're probably right... for now. Will check back for mxDateTime's
25th anniversary :-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 06 2015)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> mxODBC Plone/Zope Database Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/