Re: A structured format for dates? (future leap-seconds)

[Poul-Henning Kamp <[e-mail]>]

--------
Willy Tarreau writes:

> The epoch-based representation also has the benefit that you're not required
> to have to guess a timezone nor to be confused by ":60" resulting from a leap
> second once every few years.

(This is slightly off-topic, so I modified the subject.)

Just in case one of you end up with the category "Unforseen
consequences of green-house-gas pollution" on Jeopardy:

It used to be that, like clock-work, we would have a leap second
every 18 months, but that is no longer the case.

The first deviation was the lack of leap-seconds between 1998 and 2005.

The second deviation is that we have not had a leap-second since 2016.

Currently have no idea when, or strictly speaking even if, the
next leap-second will happen, nor what sign it may have.

Until now all leap-seconds have inserted 23:59:60, the next one
could instead delete 23:59:59.

But dont worry:  At least two members of the of the global
"leap-second-conspiracy" have tested their software for that :-)

The underlying cause is almost certain to be climate change:

Redistribution of land-locked water changes the Earth's center of
gravity, but there may also be local effects, such as reduced
core-mangle friction from less ice on Greenland.

Wikipedia has a plot going all the way back to 1972:

	https://en.wikipedia.org/wiki/File:Leapsecond.ut1-utc.svg

(The vertical jumps are the previous leap seconds.)

If you want to follow along, the official "Bulletin-A" lives here:

	https://datacenter.iers.org/plots.php?id=6

(Leap-seconds are "UT1-UTC", but notice also "dX")

May you live in (geophysically) interesting times...

Poul-Henning (Wearing his leap-second-conspiracy hat).

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[e-mail]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.