Imagine a clock but with like, four arms
January 8, 2025 10:30 PM Subscribe
s32 unix clock. A cool visualization of the original signed 32-bit integer Unix time moving toward the 2038 ending of the epoch that began in 1970. More description in David Buchanan's announcement blog post about it (from 2023, but what is time?).
It's a nice clock!
I did a little radio interview in the late 90's about the upcoming Y2k problem and how it wasn't likely to be a huge issue as a lot of people had put in a lot of work and upgrades to prevent that, but there was always the possibility that there would be some old systems that had been missed that might fail - I knew of an example for a type of valve in a gas pipeline that would failsafe shut as it suddenly believed its last maintenance date was 100 years earlier, so they all had to be updated, and a pension actuarial system that had already had to be upgraded when it started choking on specific forecast reports beyond 2000.
As we finished up, I joked we'd likely have to do something similar for the 2038 problem but I'd hopefully be out of IT by then. The host was rather boggled that we might have an issue with something that was 40 odd years away from happening, so I pointed out that much of the money needed to actually test for and resolve any issues with Y2K only became available shortly before - nobody wanted to pay to fix stuff that might be gone by the time it would be affected and/or hoped it would be some successor's problem.
Still in IT, probably still will be when 2038 rolls around, still suspect it'll only really get attention when it's 2035 or so. That said, a lot of Y2K issues were with limitations of old/cheap hardware at the time, while the unix time issue is mostly a software one and the 64-bit migration is already well advanced so should be a lot less to do.
posted by Absolutely No You-Know-What at 1:18 AM on January 9 [6 favorites]
I did a little radio interview in the late 90's about the upcoming Y2k problem and how it wasn't likely to be a huge issue as a lot of people had put in a lot of work and upgrades to prevent that, but there was always the possibility that there would be some old systems that had been missed that might fail - I knew of an example for a type of valve in a gas pipeline that would failsafe shut as it suddenly believed its last maintenance date was 100 years earlier, so they all had to be updated, and a pension actuarial system that had already had to be upgraded when it started choking on specific forecast reports beyond 2000.
As we finished up, I joked we'd likely have to do something similar for the 2038 problem but I'd hopefully be out of IT by then. The host was rather boggled that we might have an issue with something that was 40 odd years away from happening, so I pointed out that much of the money needed to actually test for and resolve any issues with Y2K only became available shortly before - nobody wanted to pay to fix stuff that might be gone by the time it would be affected and/or hoped it would be some successor's problem.
Still in IT, probably still will be when 2038 rolls around, still suspect it'll only really get attention when it's 2035 or so. That said, a lot of Y2K issues were with limitations of old/cheap hardware at the time, while the unix time issue is mostly a software one and the 64-bit migration is already well advanced so should be a lot less to do.
posted by Absolutely No You-Know-What at 1:18 AM on January 9 [6 favorites]
The proper migration should, of course, be to signed 64-bit epoch nanoseconds. That overflows too, sometime in the 23rd century. But that's Spock and Scotty's problem.
posted by notoriety public at 3:40 AM on January 9 [3 favorites]
posted by notoriety public at 3:40 AM on January 9 [3 favorites]
signed 64-bit epoch nanoseconds
Are you proposing to use messy human nanoseconds or nice tidy binary nabiseconds?
posted by flabdablet at 3:53 AM on January 9 [1 favorite]
Are you proposing to use messy human nanoseconds or nice tidy binary nabiseconds?
posted by flabdablet at 3:53 AM on January 9 [1 favorite]
Another 2^32 issue was the Deep Impact spacecraft :
On September 20, 2013, NASA abandoned further attempts to contact the craft.[78] According to chief scientist A'Hearn,[79] the reason for the software malfunction was a Y2K-like problem. August 11, 2013, 00:38:49.6, was 232 tenth-seconds (deciseconds) from January 1, 2000, leading to speculation that a system on the craft tracked time in one-tenth second increments since January 1, 2000, and stored it in an unsigned 32-bit integer, which then overflowed at this time, similar to the Year 2038 problem.[80]posted by autopilot at 4:01 AM on January 9 [2 favorites]
It took me a minute, because I couldn't see any hands at 90% of the way around. But the midnight hour, in 2038, will not have all the hands at the top like a regular clock, because we use signed integers instead of unsigned. The first second of the epoch was -0x80000000 and the last will be 0x7FFFFFFF. So I believe our happy new year will have the small red hand at the bottom and the rest at the top. Not quite as aesthetically pleasing. There's probably some good reason for using unsigned.
posted by bitslayer at 4:06 AM on January 9 [2 favorites]
posted by bitslayer at 4:06 AM on January 9 [2 favorites]
The first second of the epoch was -0x80000000
Nope. Epoch was 1970-01-01 00:00:00 UTC and the Unix date is a signed offset in seconds relative to that.
It doesn't count leap seconds, which occasionally causes teeny tiny little Y2ks; hence Google's Leap Smear.
but what is time?
Depends who you ask.
Personally I think that question drives the word "is" beyond its safe operating area, and the best answer I have is "messy".
posted by flabdablet at 4:43 AM on January 9 [3 favorites]
Nope. Epoch was 1970-01-01 00:00:00 UTC and the Unix date is a signed offset in seconds relative to that.
It doesn't count leap seconds, which occasionally causes teeny tiny little Y2ks; hence Google's Leap Smear.
but what is time?
Depends who you ask.
Personally I think that question drives the word "is" beyond its safe operating area, and the best answer I have is "messy".
posted by flabdablet at 4:43 AM on January 9 [3 favorites]
Ok, you are right that the current epoch started at zero, so I really meant that the two epoch period that the 32 bit numbers can represent started at -0x80000000. But my point stands that the end of the epoch will not have all the hands of this clock at the top.
posted by bitslayer at 5:18 AM on January 9
posted by bitslayer at 5:18 AM on January 9
An epoch is a point in time and as such it doesn't have an end. Perhaps you mean era?
posted by flabdablet at 5:23 AM on January 9
posted by flabdablet at 5:23 AM on January 9
Cool, but why are they using a signed 32-bit int? It should say "90% of the way between 0 and 4294967296 (2^32)"
Ever since I first learned about Unix time (back in the 80s) I've wondered if I'll still be around in 2038. I still wonder.
posted by crazy_yeti at 5:34 AM on January 9
Ever since I first learned about Unix time (back in the 80s) I've wondered if I'll still be around in 2038. I still wonder.
posted by crazy_yeti at 5:34 AM on January 9
You underestimate when 64 bit time overflows. It's not in the 23rd century, it is approximately 292 billion years from now.
posted by fings at 5:42 AM on January 9 [1 favorite]
posted by fings at 5:42 AM on January 9 [1 favorite]
Oops. I was wrong and the edit window is closed. It is a signed int. I guess the Founding Fathers in their infinite wisdom recognized the need to represent times before 1970. (But not before 1901).
posted by crazy_yeti at 5:45 AM on January 9
posted by crazy_yeti at 5:45 AM on January 9
Just remembered a typo somebody made at a place I worked back in the 80s where they wrote "unsinged int" and that became a running joke among all the devs for a little while.
posted by crazy_yeti at 5:47 AM on January 9 [1 favorite]
posted by crazy_yeti at 5:47 AM on January 9 [1 favorite]
why are they using a signed 32-bit int?
The retcon is so that times before Unix Epoch could also be represented as Unix times, but I'm pretty sure the real reason is that Unix was originally written in C on a machine small enough that pretty much any type could be cast to int and back without data loss.
If you read the Unix level 6 source code as described in the Lions Book, you will be amazed at how loosely typed everything is compared to anything that would be deemed acceptable by a more modern ANSI C compiler.
64 bit time overflows ... not in the 23rd century ... approximately 292 billion years from now
Sure, if you insist on keeping it only to 1 second precision. The 23rd century is when it rolls over if you keep it to the nanosecond. Which, given the aforementioned Leap Smear, I would gently suggest is likely to cause more pain than it prevents.
There really really needs to be a formal separation made between scientific time, with its nice consistent atomic-clock-derived intervals, and civil time whose main requirement is that a calendar day should last 86,400 seconds. UTC's leap seconds are an ugly, ugly hack.
posted by flabdablet at 6:05 AM on January 9 [4 favorites]
The retcon is so that times before Unix Epoch could also be represented as Unix times, but I'm pretty sure the real reason is that Unix was originally written in C on a machine small enough that pretty much any type could be cast to int and back without data loss.
If you read the Unix level 6 source code as described in the Lions Book, you will be amazed at how loosely typed everything is compared to anything that would be deemed acceptable by a more modern ANSI C compiler.
64 bit time overflows ... not in the 23rd century ... approximately 292 billion years from now
Sure, if you insist on keeping it only to 1 second precision. The 23rd century is when it rolls over if you keep it to the nanosecond. Which, given the aforementioned Leap Smear, I would gently suggest is likely to cause more pain than it prevents.
There really really needs to be a formal separation made between scientific time, with its nice consistent atomic-clock-derived intervals, and civil time whose main requirement is that a calendar day should last 86,400 seconds. UTC's leap seconds are an ugly, ugly hack.
posted by flabdablet at 6:05 AM on January 9 [4 favorites]
You underestimate when 64 bit time overflows. It's not in the 23rd century, it is approximately 292 billion years from now.
That’s if it’s seconds. If it’s nanoseconds, it’s 23rd century.
posted by notoriety public at 6:19 AM on January 9
That’s if it’s seconds. If it’s nanoseconds, it’s 23rd century.
posted by notoriety public at 6:19 AM on January 9
That 9F to A0 transition is fucking with my head.
You've been hexed!
posted by notoriety public at 7:18 AM on January 9 [6 favorites]
You've been hexed!
posted by notoriety public at 7:18 AM on January 9 [6 favorites]
When I go night swimming in the river, which I'm just this minute about to head off and do, I like to swim while counting the strokes because this is meditative and calming.
To keep that process robust in the face of the kind of internal distractions that my preferred herbal adjunct to the night swimming experience frequently brings on, it helps me to use a counting system that fits in nicely with 4/4 rhythm so I can quickly re-sync to the correct count for beat 1 whenever I momentarily lose track.
Counting backwards in hexadecimal is a real help with that because it makes beat 1 occur consistently on one of just four possible ones digits - F, B, 7 or 3 - and the sixteens digit clocks over between bars instead of in the middle. It's also quite rare that I get distracted enough to lose track of which bar in each group of four I'm currently in, or the feel of where beat 1 is supposed to be.
Counting backwards also allows me to commit easily to doing a pre-set amount of strokes; the count is heading for a nice well-defined end point at zero, so there's really no opportunity to pike out and give up half way.
It's all quite pleasing, the way all those endless hours of poring over data dumps as a younger man have paid off in my retirement.
posted by flabdablet at 7:21 AM on January 9 [4 favorites]
To keep that process robust in the face of the kind of internal distractions that my preferred herbal adjunct to the night swimming experience frequently brings on, it helps me to use a counting system that fits in nicely with 4/4 rhythm so I can quickly re-sync to the correct count for beat 1 whenever I momentarily lose track.
Counting backwards in hexadecimal is a real help with that because it makes beat 1 occur consistently on one of just four possible ones digits - F, B, 7 or 3 - and the sixteens digit clocks over between bars instead of in the middle. It's also quite rare that I get distracted enough to lose track of which bar in each group of four I'm currently in, or the feel of where beat 1 is supposed to be.
Counting backwards also allows me to commit easily to doing a pre-set amount of strokes; the count is heading for a nice well-defined end point at zero, so there's really no opportunity to pike out and give up half way.
It's all quite pleasing, the way all those endless hours of poring over data dumps as a younger man have paid off in my retirement.
posted by flabdablet at 7:21 AM on January 9 [4 favorites]
Very cool idea, and the source code (view-source:https://retr0.id/stuff/2038/) shows a nice simple example of how to use HTML canvas.
posted by milnak at 10:04 AM on January 9
posted by milnak at 10:04 AM on January 9
« Older There’s an emu on the loose on the Eastern Shore | Where does American socialism stop and American... Newer »
posted by inexorably_forward at 1:11 AM on January 9