I have an idle fascination with matters of time and date, so I have written a number of articles and bits of code — although it’s just a hobby with no ambitions to be practical or useful to anyone but me (and mostly not even then).
Counting the days - tiny routines for converting
Gregorian dates into linear counts, like Julian day numbers or Unix
The date of the count - a small routine for converting linear day counts into Gregorian dates.
Most implementations I have seen of these functions use some kind of iterative search to find the right result. My versions use arithmetic like Zeller’s congruence to go directly to the result.
iCalendar is wrong - standard calendaring data models have a confusing way to handle time zones, which could (in theory) be improved.
Timezone display by MUAs can be confusing (and improved) in a similar way.
A related annoyance is that the Unicode CLDR has standard “friendly” localized descriptions for time zone names, which are very confusing and often wrong for more than half the year.
I wrote a little
datez utility in Rust to help me deal with these problems.
There’s a spectacular clock in the centre of Cambridge. I wrote a few blog articles about it when it was new in 2008/9:
I publish cryptographically signed lists of leap seconds in the
leapsecond.dotat.at in various formats:
AAAA - the date and time of the last second in months that end
with a leap second, plus the last second of the known validity
period if that is not a leap second, in binary-coded decimal.
TXT - the intervals between leap seconds in months, separated by
- for positive or negative leap seconds, and
terminated by a
TYPE65432 - compressed binary encoding of the
URI - a link to the specification
HINFO - brief descriptions of the other record types
I have a specification and reference implementation in Rust for my
compact leap second list formats (
The last leap second was at the end of 2016, and the current gap is going to be longer than the previous record of 7 years (1999-2005).
Unlike last time, the earth has sped up so much that since the end of 2020 it now takes less than 24 * 60 * 60 seconds to rotate each day (it always used to be longer). This brings us the prospect of a negative leap second !!!!!
I wrote a blog article in November 2020 when this first came to my attention.
There was an awkward gap from the start of TAI to the start of UTC, when the difference between atomic time and civil time was represented with varying “rubber seconds”. I suggested proleptic UTC as a way to make it easier to bridge the gap with fixed atomic seconds.
I have a Rust program that makes a guesstimate of when the next leap second will occur, and whether it will be positive or negative. It uses the long-term projection formula from IERS Bulletin A.
My off-the-cuff wittering on this topic occurs on Twitter, where they are hard to find and difficult to navigate, so I have collected them here:
I pay attention to three of the IERS bulletins (C and D by subscribing to email notifications):
Bulletin A - weekly forecast of earth rotation parameters, which I use for guessing about the next Bulletins C and D
Bulletin C - leap second announcements, published every 6 months: in early January, regarding the possible leap second at the end of June; and in early July, regarding the possible leap second at the end of December.
Bulletin D - announcements of DUT1 in increments of 0.1 second (as required by ITU TF.460), published irregularly as necessary.
ITU TF.460 is a standard for radio time signals, and the specification for leap seconds
leapsecond.com - Tom Van Baak’s time nut pages
Steve Allen’s pages on leap seconds - I often refer to his extrapolation of the difference between TAI and UT1