[Datetime-SIG] Calendar vs timespan calculations...
tim.peters at gmail.com
Mon Aug 3 18:59:26 CEST 2015
>> I'm happy with a strict tzinfo at least having the ability
>> to deal with leap seconds -- then those that care can
>> make it work.
> I'm a bit confused about what the strict tzinfo object has to do with
> leap seconds.
Not much, except to the extent someone may want datetime arithmetic to
reflect leap second reality. Using tzstrict is the suggested way to
spell "I want timeline arithmetic, not classic arithmetic". Whether
arithmetic accounts for leap seconds is the same issue, mutatis
mutandis, as whether arithmetic accounts for DST transitions, and also
whether arithmetic accounts for changes to a timezone's standard UTC
> Leap seconds are more like leap years than DST transitions. (Except
> that we don't know when they will occur in the future). An extra
> second (:60) is added, rather than repeating one. So it is never
> ambiguous what is meant.
This, alas, is off. First, "leap seconds" may also be removed,
although that hasn't yet been done. The Earth's rotation doesn't
always slow down - sometimes it speeds up. Nobody knows - and nobody
_can_ know now - whether it will ever speed up enough long enough to
trigger a leap second removal.
Second, adding a leap second, adding an hour (at the end of DST), and
adding a day in a leap year are all very much the same.; Adding an
hour at the end of DST causes a "repeated hour" on any clock
restricted to showing 24 hours per day. In exactly the same way,
adding a leap second causes a "repeated second" on any clock
restricted to showing 60 seconds per minute. And adding a leap day
_would_ cause a "repeated day" on any calendar restricted to showing
only 28 days in February. The only real difference is that _all_
calendars _do_ show 29 days in a leap year February, _no_ clocks show
25 hours in an end-of-DST day, and _almost no_ clocks show 61 seconds
in a leap-second-added minute.
> And all time zones handle them the same, yes?
Eh - probably all the ones people have in mind. But, e.g., TAI
("atomic time") has no concept of leap seconds, DST transitions,
changes of standard offset, or any other kind of adjustment. Whether
someone wants to call that a "time zone", and go on try to write a
tzinfo class to model it, is up to them.
> So consideration for leap seconds belongs in with the code that
> handles converting the Gregorian calendar representation to/from a
"Arithmetic", but all kinds of transitions are uniform in this respect
- there's nothing special in this respect about leap seconds.
> The other consideration is that time parsing code can't barf on a 60th
> second, just like it can't barf on feb 29th.
Sure it can. It's not even possible to know whether "second=60" makes
any sense for infinitely ;-) many datetimes in the future. It's only
theoretically possible to know for datetimes no later than about 6
months in the future (although that safe window on the future will
relentlessly shrink over time). There's a delightful eternity of
bikeshedding yet to be endured here ;-)
> All this code is in datetime, isn't it?
There are ways to parse strings all over the place, including in
user-written code we know nothing about. OS services and the std C
libraries have their own ideas about this stuff, and Python exposes
some of what they supply too.
> Please tell me there are no leap seconds in the middle of DST transitions!
Leap-second adjustments occur at a fixed time in UTC, so each such
adjustment occurs in every possible hour on local clocks. So it's
theoretically possible to coincide with some location's DST rules. I
don't know whether any such collisions have actually occurred. I
doubt it. So far leap second transitions have occurred only at the
end of the last days of a June or December, which I guess (but don't
know) are far away from all DST transitions currently in use. But if
this insane scheme isn't changed, we'll _eventually_ need to suffer at
least one leap-second adjustment every day (well, "we" in the sense of
humanity - you and I will be blissfully dead by then ;-) ).
> By the way, I've generally been of the opinion that leap seconds
> didn't matter to me, or most people. But apparently there have been 26
> leap seconds since 1972. That's actually quite a bit, even for people
> that aren't doing atomic physics....
It doesn't matter at all to most people or applications: most only
care what the local clock says, and couldn't care less how many SI
seconds separate "now" from, e.g., "same time next year". Given the
history to date of leap second adjustments, the difference between
"now" and "same time next year" differs by at most one second
(comparing timeline/strict subtraction to classic/naive subtraction).
Applications that need reliable, surprise-free accounting of durations
over arbitrarily long spans should use TAI: that's what it was
designed for. It's a relentlessly uniform running count of elapsed SI
seconds. TAI also has a representation in an idealized Gregorian
calendar, which is pretty much identical to datetime's notion of
"naive time". UTC is currently _defined_ as an offset to TAI, but the
offset changes over time in unpredictable was (via "leap seconds").
Note that the definition of UTC changes over time too. Currently the
TIA "second" and the UTC "second" are identical durations, but in
earlier days the duration of a UTC second changed over time too, so
that leap seconds _weren't_ needed to keep UTC time a good
approximation to notions of solar time.
So it's flatly insane in a scientific context concerned with durations
to use something other than TAI. What a UTC datetime "really means"
has changed over time, and will almost certainly change again. Times
recorded in TAI are intended to have the same meaning until the
universe ends. "Doctor! Doctor! It hurts when I do this!" ...
More information about the Datetime-SIG