Looks like we'll have another second in 2016:
leap-second-2016-atomic-clocks
Chris Adams:
> Leap seconds are inserted to keep the atomic clocks synced with an
> arbitrary time base (that is guaranteed to vary forever). There's
> nothing magic about having noon UTC meaning the Sun is directly over 0°
> longitude; if we didn't insert leap seconds, it would have drifted
> slightly, but so what?
Here is "so what". From my blog, earlier this year: "In defense of
calendrical irregularity": Eric S. Raymond
I’ve been getting deeper into timekeeping and calendar-related
software the last few years. Besides my work on GPSD, I’m now the tech
lead of NTPsec. Accordingly, I have learned a great deal about time
mensuration and the many odd problems that beset calendricists. I
could tell you more about the flakiness of timezones, leap seconds,
and the error budget of UTC than you probably want to know.
Paradoxically, I find that studying the glitches in the system (some
of which are quite maddening from a software engineer’s point of view)
has left me more opposed to efforts to simplify them out of
existence. I am against, as a major example, the efforts to abolish
leap seconds.
My reason is that studying this mess has made me more aware than I
used to be of the actual function of civil timekeeping. It is to allow
humans to have consistent and useful intuitions about how clock time
relates to the solar day, and in particular to how human circadian
rhythms are entrained by the solar day. Secondarily to maintain
knowledge of how human biological rhythms connect to the seasonal
round (a weaker effect but not a trivial one).
Yes, in theory we could abolish calendars and timestamp everything by
atomic-clock kiloseconds since an epoch. And if there ever comes a day
when we all live in completely controlled environments like space habs
or dome colonies that might actually work for us.
Until then, the trouble with that sort of computer-optimized timestamp
is that while it tells us what time it is, it doesn’t tell us what
*kind* of time it is – how the time relates to human living. Day? Night?
Season?
Those sideband meanings are an important component of how humans use
and interpret time references. Yes, I know January in Australia
doesn’t mean the same thing as January in the U.S. – the point is that
people in both places have stable intuitions about what the weather
will be like then, what sorts of holidays will be celebrated, what
kind of mood is prevalent.
I judge that all the crap I go though reconciling scientific absolute
time to human-centered solar time is worth it. Because when all is
said and done, clocks and calendars are human instruments to serve
human needs. We should be glad when they add texture and meaning to
human life, and beware lest in our attempts to make software easier to
write we inadvertently bulldoze away entire structures of delicate
meaning.
UPDATE: There is one context, however, in which I would cheerfully
junk timezones. I think timestamps on things like file modifications
and version-control commits should always be kept, and represented, in
UTC, and I’m a big fan of RFC3339 format as the way to do that.
The reason I say this is that these times almost never have a
human-body-clock meaning, while on the other hand it is often useful
to be able to compare them unambiguously across timezones. Their usage
pattern is more like scientific than civil time.
On Sun 2016-07-10T11:27:33 +0300, Saku Ytti hath writ: So how can we solve the problem? Immediately and long term?
The ITU-R had the question of leap seconds on their agenda for 14
years and did not come up with an answer. Their 2015 decision was to
drop the question and ask an alphabet soup of international acronym
agencies to come up with something better by 2023.
The problem remains that simply abandoning leap seconds has the effect
of redefining the calendar, and Pope Gregory's last attempt to do that
took 300 years to consolidate. For time scales there are three
desirable goals, but it is only possible to pick two
Pick Two - Issues involved in computer time stamps and leap seconds
Leap second handling code is not well-tested and is an ultimate corner
case. There's been debate about abolishing leap seconds; with all the
every-day bugs people have to deal with, few people set up a special
test environment to handle something that may never happen again (until
you get less than six months warning that it'll happen at least once
more), and even then, tests tend to focus on what broke before, because
it is really hard to test EVERYTHING.
If this particular issue is your beat -- or your avocation -- you really should
read both these blog postings, and all their comments; they are nearly
comprehensive:
falsehoods-programmers-believe-about-time and
more-falsehoods-programmers-believe-about-time
They are also both funny as hell.
To myself be comprehensive, I should point out a companion piece about names:
falsehoods-programmers-believe-about-names
and there are similar lists for phone numbers, geography, civil addresses and gender,
linked from this thread.
If you write any code that has to interface with the outside world, these are pieces
I think you should read at least annually.
Cheers,
-- jra
