The Thorny Problem of Keeping the Internet's Time | Hacker News Reader

The Thorny Problem of Keeping the Internet's Time

newyorker.com

149 pointsmitchbob41 comments

Found this on a deep man page, but I can't remember which one:

Our units of temporal measurement, from seconds on up to months, are so complicated, asymmetrical and disjunctive so as to make coherent mental reckoning in time all but impossible. Indeed, had some tyrannical god contrived to enslave our minds to time, to make it all but impossible for us to escape subjection to sodden routines and unpleasant surprises, he could hardly have done better than handing down our present system. It is like a set of trapezoidal building blocks, with no vertical or horizontal surfaces, like a language in which the simplest thought demands ornate constructions, useless particles and lengthy circumlocutions. Unlike the more successful patterns of language and science, which enable us to face experience boldly or at least level-headedly, our system of temporal calculation silently and persistently encourages our terror of time. ... It is as though architects had to measure length in feet, width in meters and height in ells; as though basic instruction manuals demanded a knowledge of five different languages. It is no wonder then that we often look into our own immediate past or future, last Tuesday or a week from Sunday, with feelings of helpless confusion. ... --Robert Grudin, 'Time and the Art of Living'.

Talk to any developer who's been around for any period of time, and they'll tell you that dealing with time is a PITA.

What's bad is that there's no real thought given to interplanetary time. It's alluded to occasionally in SF, but there are no RFCs etc about it.

Earth has UTC. Mars will presumably have MTC. What about things wandering about? How will that be mapped?

More importantly, what happens to timestamps, GUIDs, etc?

Real thought has indeed been given to interplanetary time (even by the subject of TFA). You may find this of interest:

https://webcache.googleusercontent.com/search?q=cache:pyKjMo... (forgive the cache but a postscript file is more easily viewed this way in the browser).

Few other relevant pointers: https://en.wikipedia.org/wiki/Deep_Space_Atomic_Clock and https://en.wikipedia.org/wiki/Barycentric_Coordinate_Time

There is an implementation: Martian Time in Hare[0], which is based on the Martian Business Calendar[1]

[0] https://harelang.org/blog/2022-08-01-martian-time-in-hare/

[1] http://www.bdm.id.au/calendar/mars_calendar.html

> Earth has UTC. Mars will presumably have MTC.

If UTC doesn't work on Mars, it's false advertising, and we should really change the name.

wait until you hear about the World Series.

UTC kind of works on Mars, but doesn’t really make much sense there, because it includes the leap second hack to make sunrises on Earth happen within a second of where they would have been with constant-length 24-hour days while keeping constant-length seconds. If you don’t care about that, use TAI, which is the simple monotonic counter UTC is based off of, or a trivial transform such as GPS time. (If you need so much precision that differences in the “constant-length” second due to motion and gravity matter, you shouldn’t be listening to me.)

I think it’s important to realize that the precisions we use for everyday time measurement are absolutely ludicrous. If you tell a physicist you can get seven significant figures of a value on a common household device, you’ll be laughed out of the room, and yet you know when a new year starts down to the second (1 : 3 × 10⁷) and don’t think much about it. Hell, you can have that to the millisecond (ten figures) if you care to, although it starts to get mildly tricky to actually use the result. This is the kind of precision that usually requires tens of thousands (in the former case) to millions (in the latter one) of dollars in equipment, knowledge of all kinds of tricky physical effects, and a trip to your country’s metrology institute for calibration. At best.

It’s a marvel that time measurement allows us to get away with a small collection of historical and convenience hacks here.

He's joking about the "universal" in the UTC acronym. If UTC doesn't work on Mars, it's hardly "universal".

I mean, it would work in the sense that you could use it to count time, but the units wouldn't have any practical relation to the planet's rotation.

TAI wouldn't work on Mars either. Mars is higher up the Sun's gravity well. To keep Mars on TAI would require adding a leap second every 5-6 years as the divergence is ~0.18 seconds every year.

There is a time standard that theoretically covers both Earth and Mars, along with the rest of the solar system: Barycentric Coordinate Time (TCB): https://en.wikipedia.org/wiki/Barycentric_Coordinate_Time But to achieve a singular, shared reference clock you have to give up everything else TAI advocates believe is important in a time standard.

UTC-style time should never be used as unique identifiers by itself, and computer clocks telling such time should generally not be assumed to always have monotonically increasing output. Most systems are sufficiently sane that they don’t critically rely on such assumptions.

The most interesting issue regarding Mars is that time elapses slightly faster on Mars than on Earth due to relativistic time dilation (according to https://space.stackexchange.com/a/33592, by 0.17 seconds per year). Conversion between Mars and Earth calendars will eventually have to take that into account, possibly with some kind of leap second mechanism.

Overall, I don’t think it will be too much different than what we already do on earth with regard to different calendars and timezones. The one novel aspect will be the difference in length of day.

Regarding a common solar system time, there is BCT and BDT [0][1]. Astronomers already have to deal with that. Another interesting webpage about time scales is [2][3].

[0] https://en.wikipedia.org/wiki/Barycentric_Coordinate_Time

[1] https://en.wikipedia.org/wiki/Barycentric_Dynamical_Time

[2] https://www.ucolick.org/~sla/leapsecs/timescales.html

[3] https://www.ucolick.org/~sla/leapsecs/deltat.html

This is a really great article that doesn’t shy away from technical aspects while putting a human face on NTP. It’s really cool to learn the history behind something we take for granted.

I also really enjoyed reading this; the mix of computer science & history was well balanced and kept my interest.

It makes me think there should be a CompSci history class taught in college.

This quote hits hard

    Coders who contribute to it, she said, should feel proud enough to declare, “Everyone uses the software, it’s in everything, and I wrote it!” It’s striking how few people know Mills’s name, given how many know the pseudonym of whoever created Bitcoin."

I never heard of Mill before, and am just glad to have read and known this critical man and technology to internet infrastructure.

I mean, I think Satoshi Nakamoto is notorious precisely because of his pseudonymous nature. If he'd used his real name, I doubt he'd get nearly as much attention.

Relevant xkcd: https://xkcd.com/2347

I was a little sad to read that Mills in fact lives in Delaware, not Nebraska. I always had a sneaking suspicion that this comic was NTP-related.

To be fair, that's only off by 0.0069625621 seconds. Since time advances at the speed of light, you could say everyone lives in Nebraska and still be correct well within the margin of error.

The title text for the image implies it might be about ImageMagick, but that's probably dated now since the likes of vips

I had written David and NTP down as a podcast episode idea. Never expected to get scooped by the New Yorker.

An intricate topic like this works better as a written article. Podcasts are more for people who want to listen to some lowbrow stuff while driving.

Sorry but this is just your opinion. I Listen to tons of very technical podcasts and it works great. If you are interested in technology, check out the omega tau podcast for example.

Or, ironically, the podcast of the guy he responded to, adamgordonbell: https://corecursive.com/

It's a podcast I've really been enjoying for a few years now. It used to be a little more technical (as the name, corecursive, kinda implies), but found a niche in interviewing people more about the people than the tech they're knowledgeable about, which is also very pleasant. Anyway, I encourage you to listen to both an early and a recent episode to find out if you like it.

This article is pretty lowbrow, not much technical meat and lots of ephemeral kibitzing.

I call them subscription mp3 audio files.

Do it anyways. Dave Mills and NTP deserves it.

Also: Olson timezone database and its various maintainers. Paul Eggert is the current maintainer, I think. Arthur David Olson could be interesting as well.

> Mills wrote, in a 2003 paper. “Today, the Sun never sets or even gets close to the horizon on NTP.”

I'd guess the capitalized "Sun" was a pun, for the Sun Microsystems computers that still ran much of the Internet. For example: https://www.sunmanagers.org/1992/1188.html

It’s a play on a well-known description of the extent of the British Empire in its time. And which still, if you squint a bit, remains true today, at least according to Randall Munroe*

* https://what-if.xkcd.com/48/

Thanks, great information. (I'd heard the saying, but I see capitalized Sun so much to refer to the computers, that I guess I always read it that way, and forgot our star is also capitalized.)

Sun definitely advanced the state of the art. They had a well written set of three Blue Papers on timekeeping in SunOS, if you can find them after Oracle ate everything. Their implementation was mostly Mills ntpd but had to tweak it for their motherboard realtime clocks. Both ntpd and the Sun RTC were the source of much debugging amusement. But that's another story :-)

Computerphile has a really amusing (sort of) video on the related issue of how to translate between internet time and local time zones (though they have a different opinion about the wisdom of 'leap smears' vs 'leap seconds'):

https://www.youtube.com/watch?v=-5wpm-gesOY

Note that the common-sense notion that time intervals are fixed fails when relativistic concepts are introduced. Atomic clocks get out of sync due to being in different relativistic frames (satellites vs. ground, for example). Hence designating a 'universal time' is always going to be somewhat arbitrary.

https://blog.swiftnav.com/relativistic-correction/

I’ve recently gotten curious about how accurate my computers clock is, and the answer is “usually, only vaguely accurate down to one second”

I check via time.gov, and it’s often off by .5-.8s which just seems kinda insane to me. On my phone it’s always accurate to around .01s.

I think I have a guess as to why though. The bios clock might not save milliseconds[0]. So whenever I turn the computer on in the morning, it’s always not synced to the second. And windows just doesn’t care? Even if it’s off by 900ms and I manually go in and try to resync it often won’t bother. I have to manually change it to something blatantly wrong, then resync. And only then will it will finally be accurate to to .01s.

This seemingly default level of imprecision to nearly 1 full second is very surprising to me. I’m curious if that affects anything.

[0] not 100% certain about this. Maybe I just have insane second-per-day drift. I’ve seen the computer be off by as much as 1.3s, which doesn’t quite match my theory, but that error is enough to resync on its own.

I have not checked if in recent versions of Windows there has been any change, but previously by default the computer clock was synchronized with a time server only once per day, so until the next synchronization it is normal to accumulate a time difference up to one or two seconds.

I do not know how many Linux distributions enable by default a ntpd daemon, but I have always enabled it on any computer running Linux or FreeBSD.

When a ntpd is active, it adjusts continuously the local clock based on comparisons with NTP servers, so the time cannot be wrong by more than a few milliseconds. Therefore the error becomes 100 to 1000 times less than without ntpd.

The time differences between computers using NTP on the same LAN are smaller, usually of a few hundred microseconds. For even better synchronization within a LAN, the Precision Time Protocol must be used.

If you have systemd it enables a timesyncd service which is NTP.

To be precise, it's SNTP, not full-fledged NTP:

> The systemd-timesyncd service implements SNTP only. This minimalistic service will step the system clock for large offsets or slowly adjust it for smaller deltas. Complex use cases that require full NTP support (and where SNTP is not sufficient) are not covered by systemd-timesyncd.

SMTP is really only intended for use in edge-of-graph instances where there is no further dependence on the output e.g. a wall clock. General-purpose computers should all be using NTP.

It sounds like you may have your solution, but for linux users with similar concerns I'll note:

Not sure if it's available on Windows: `ntpd -g` can perform a big update on first check. https://serverfault.com/a/16513/513049

I was going to mention ntpdate, but in searching I've learned it's been deprecated for a decade, since September 2012, https://serverfault.com/a/16513/513049.

Time has been on my mind a lot lately, testing the OCP's Time Card, working with bringing up PTP on the Raspberry Pi CM4, and most recently interviewing Dr. Demetrios Matsakis, who was one of the people who coordinated UTC for many years (and now works as chief scientist at a local clock/timing company).

It's always fascinating how certain individuals can really push things forward in a much greater way than you'd think. NTP changed a lot of what's possible online and in software, by giving a reliable more centralized timing solution for much of the world (still to this day).

But talking to some actual experts in the field (like Dr. Matsakis), it's fascinating some of the additional problems you encounter when Internet, LAN, and even GPS connectivity can't be guaranteed, but you still need many devices with microsecond-level accuracy for long periods of time.

Archived: https://archive.ph/tmbk6

https://www.nwtime.org/current-members-donors/

Don’t forget to add “ maxdelay 0.05/0.1/0.2” across your three NTP server settings, lest you get hit by MitM NTP attack.

You’re welcome.

Nice article. Of course it's more of a human interest piece, but still, too bad they don't talk about PTP at all.

Reply on news.ycombinator.com