Happy new year, and from a technology perspective, also happy leap second.
As always, when there’s a leap second, people get a chance to debug their timekeeping code. I guess if they happen frequently enough the code will get better exercise and some bugs will be shaken out. Generally every time some government messes with timekeeping, a small army of programmer gets a few hours of work to adjust with some occasional unplanned downtime.
The biggest issue identified was at Cloudflare, a distributed system for web cachine. Some DNS lookups causing 5xx errors due to leap second bug is the incident report.
Starting at 00:00 UTC on January 1, 2017, CNAME resolutions on some machines stopped working due to a bug triggered by the universal addition of one leap second, which affected both some authoritative DNS and origin DNS lookups, causing 5xx errors.
The future timekeeping bug that’s most likely to create worldwide angst on the scale of Y2K is the Year 2038 problem , which I’m counting on helping fix to fund my retirement.
TimeAndDate News has a time zone news feed, which is useful to track worldwide adjustments to and from Daylight Savings Time.
Finally in timekeeping news and notes, the CoreOS help pages for timekeeping illustrate the importance of keeping good time within a computing cluster.
CoreOS clusters use NTP to synchronize the clocks of member nodes, and all machines start an NTP client at boot. CoreOS versions later than 681.0.0 use systemd-timesyncd(8) as the default NTP client. Earlier versions used ntpd(8). Use systemctl to check which service is running:
“Systemd is eating the world”, and one of the things it has eaten is timekeeping. One of the old CoreOS bugs, systemd-timesyncd not as precise as ntpd , reports that because of systemd-timesyncd’s less precise timekeeping there are problems with Deis and Ceph. The bug report is from 2015 and was closed due to inactivity, but if you have weird problems with CoreOS, Deis, and Ceph, check your clocks!
Hail truechimers, exit falsetickers!