WEBVTT 00:00:00.000 --> 00:00:05.519 At exactly 3 .14 a .m. on January 19, 2038, millions 00:00:05.519 --> 00:00:08.419 of computer systems around the world are, they're 00:00:08.419 --> 00:00:10.859 suddenly gonna believe it's the year 1901. Right. 00:00:11.279 --> 00:00:13.759 It's wild to think about. It really is. I mean, 00:00:13.779 --> 00:00:16.399 mortgages could instantly expire. Banking software 00:00:16.399 --> 00:00:19.719 could just self -destruct. And, you know... critical 00:00:19.719 --> 00:00:21.699 satellite communications might actually fail. 00:00:21.899 --> 00:00:23.820 And the craziest part of all of this impending 00:00:23.820 --> 00:00:27.079 chaos is that it traces back to this cobbled 00:00:27.079 --> 00:00:30.059 together digital stopwatch created by just a 00:00:30.059 --> 00:00:33.000 few engineers back in 1970. Welcome to today's 00:00:33.000 --> 00:00:35.100 Deep Dive. We are so glad you're here with us 00:00:35.100 --> 00:00:37.759 joining the conversation because today we're 00:00:37.759 --> 00:00:40.320 exploring this invisible, relentless clock that 00:00:40.320 --> 00:00:42.719 powers, well, pretty much every single piece 00:00:42.719 --> 00:00:45.000 of modern technology you use. Yeah, we really 00:00:45.000 --> 00:00:47.140 operate under this illusion that underneath our 00:00:47.140 --> 00:00:50.060 glowing screens there's this highly sophisticated, 00:00:50.259 --> 00:00:52.359 perfectly engineered master clock, you know, 00:00:52.679 --> 00:00:55.060 managing our digital lives. But our source for 00:00:55.060 --> 00:00:57.039 this journey, which is a really comprehensive 00:00:57.039 --> 00:00:59.219 Wikipedia article on something called Unix time, 00:00:59.799 --> 00:01:02.350 shows that's just not true. Our mission today 00:01:02.350 --> 00:01:06.090 is to uncover the messy, chaotic history of this 00:01:06.090 --> 00:01:09.950 clock, its bizarre mathematical quirks, and those 00:01:09.950 --> 00:01:12.310 impending doom dates that engineers are currently 00:01:12.310 --> 00:01:14.450 scrambling to fix. Exactly, because if you pull 00:01:14.450 --> 00:01:16.189 up the floorboards of the internet and actually 00:01:16.189 --> 00:01:18.650 examine the foundation, the master timekeeper 00:01:18.650 --> 00:01:22.390 is less of a modern marvel and more of a deeply 00:01:22.390 --> 00:01:25.010 flawed artifact from the disco era. Okay, let's 00:01:25.010 --> 00:01:28.120 unpack this. You next time. What exactly is it? 00:01:28.640 --> 00:01:31.019 At its most basic level, Unix time is simply 00:01:31.019 --> 00:01:33.219 a system that measures the passage of time by 00:01:33.219 --> 00:01:35.140 just counting the number of non -leap seconds 00:01:35.140 --> 00:01:39.340 that have elapsed since exactly 000 .000 UTC 00:01:39.340 --> 00:01:42.620 on January 1st, 1970. Which is a specific moment 00:01:42.620 --> 00:01:44.799 in computing known as the Unix epoch. Right. 00:01:44.840 --> 00:01:47.239 It's just a purely linear, relentless count. 00:01:47.400 --> 00:01:49.060 Like, the core number doesn't know what a month 00:01:49.060 --> 00:01:51.159 is. It doesn't care about time zones. No, not 00:01:51.159 --> 00:01:53.420 at all. And it certainly doesn't observe daylight 00:01:53.420 --> 00:01:55.219 saving time. It literally just counts seconds. 00:01:55.359 --> 00:01:57.719 One, two, three, four. taking upward into infinity. 00:01:58.019 --> 00:02:00.560 And if a computer needs to represent a date before 00:02:00.560 --> 00:02:03.680 January 1st, 1970, I read it just flips the script 00:02:03.680 --> 00:02:05.540 and uses negative numbers, right? Yeah, exactly. 00:02:05.620 --> 00:02:07.719 It just counts backwards from that zero point 00:02:07.719 --> 00:02:10.919 using a minus sign. I just picture it like someone's 00:02:10.919 --> 00:02:14.280 standing in a room, and right as the ball dropped 00:02:14.280 --> 00:02:17.419 in Times Square on New Year's Day, 1970, they 00:02:17.419 --> 00:02:20.000 just clicked a giant, relentless stock watch. 00:02:20.060 --> 00:02:21.819 That's a great way to look at it. And they just 00:02:21.819 --> 00:02:25.090 decided to let it run forever. So every single 00:02:25.090 --> 00:02:29.770 day in this system contains exactly 86 ,400 seconds. 00:02:29.990 --> 00:02:32.370 But the secret the source material reveals, though, 00:02:32.710 --> 00:02:35.030 is that the origin of this giant stopwatch was 00:02:35.030 --> 00:02:37.990 just entirely trial and error. Total guesswork. 00:02:38.110 --> 00:02:40.770 Yeah, it wasn't born out of some grand, meticulously 00:02:40.770 --> 00:02:43.969 calculated scientific consensus at all. In fact, 00:02:44.289 --> 00:02:46.889 in the earliest versions of Unix time, they weren't 00:02:46.889 --> 00:02:49.169 even counting by whole seconds. Because the early 00:02:49.169 --> 00:02:51.639 days were completely chaotic. The original system 00:02:51.639 --> 00:02:53.919 actually counted at a rate of 60 Hertz, meaning 00:02:53.919 --> 00:02:56.300 it was ticking 60 times every single second. 00:02:56.520 --> 00:02:59.400 Which sounds completely excessive. It does. And 00:02:59.400 --> 00:03:02.280 why did they do that? Simply because that happened 00:03:02.280 --> 00:03:05.520 to be the hardware system clock rate of the specific 00:03:05.520 --> 00:03:08.080 early computers they were building the operating 00:03:08.080 --> 00:03:10.719 system on. Right. And tying the software's concept 00:03:10.719 --> 00:03:13.620 of time directly to the hardware's electrical 00:03:13.620 --> 00:03:17.280 pulse makes sense from a localized engineering 00:03:17.280 --> 00:03:19.969 perspective. Sure. In the moment. But. Mathematically, 00:03:20.210 --> 00:03:23.849 it created a massive bottleneck. The system stored 00:03:23.849 --> 00:03:27.270 this time value as a 32 -bit integer. Basically 00:03:27.270 --> 00:03:30.710 a small digital box. Exactly. And when you are 00:03:30.710 --> 00:03:33.490 eating up 60 numbers every single second, the 00:03:33.490 --> 00:03:35.830 digital box you use to store those numbers fills 00:03:35.830 --> 00:03:38.460 up incredibly fast. Yeah, according to the source, 00:03:38.780 --> 00:03:42.219 that 60 Hertz clock was overflowing every 2 .26 00:03:42.219 --> 00:03:43.919 years. It's just running out of room. Right. 00:03:44.039 --> 00:03:45.960 You'd literally have to reset the foundational 00:03:45.960 --> 00:03:48.259 clock of your entire operating system every couple 00:03:48.259 --> 00:03:50.319 of years just because it ran out of mathematical 00:03:50.319 --> 00:03:52.580 space. So to prevent the computers from just 00:03:52.580 --> 00:03:55.039 totally crashing, the engineers kept physically 00:03:55.039 --> 00:03:57.759 moving the starting line. They shifted the epoch 00:03:57.759 --> 00:04:01.689 to midnight. on January 1st, 1971. And then a 00:04:01.689 --> 00:04:04.189 year later, they had to move it again to January 00:04:04.189 --> 00:04:08.330 1st, 1972. It was just this completely unsustainable 00:04:08.330 --> 00:04:11.830 patch job. Until finally they realized the 60 00:04:11.830 --> 00:04:14.889 Hertz system was ridiculous They needed to slow 00:04:14.889 --> 00:04:17.329 the stopwatch down to well literally buy themselves 00:04:17.329 --> 00:04:19.910 more time They had to so they changed the system 00:04:19.910 --> 00:04:22.769 to count by whole seconds instead of sixtieths 00:04:22.769 --> 00:04:25.050 of a second and they moved the epoch back to 00:04:25.050 --> 00:04:28.370 January 1st 1970 and the reason they picked 1970 00:04:28.370 --> 00:04:32.310 is Maybe the most jarring detail in all of this. 00:04:32.310 --> 00:04:35.370 Oh, absolutely It wasn't for some grand astronomical 00:04:35.370 --> 00:04:38.129 alignment. Nope. It wasn't for historical significance. 00:04:38.310 --> 00:04:40.290 They picked it arbitrarily because they considered 00:04:40.290 --> 00:04:42.810 it, quote, convenient. Which is fascinating when 00:04:42.810 --> 00:04:44.790 you compare it to how other operating systems 00:04:44.790 --> 00:04:47.350 handle time, like Windows, for example. Right. 00:04:47.410 --> 00:04:49.670 What do they do? Well, Windows uses an epoch 00:04:49.670 --> 00:04:52.660 that starts on January 1st, 1601. And it tracks 00:04:52.660 --> 00:04:55.980 time in 100 nanosecond intervals. OK, very precise. 00:04:56.279 --> 00:04:58.379 Yeah. And they chose 1601 specifically because 00:04:58.379 --> 00:05:01.319 it marks the beginning of a 400 -year Gregorian 00:05:01.319 --> 00:05:04.379 leap cycle. So it has this very firm mathematical 00:05:04.379 --> 00:05:06.180 grounding. It actually makes sense. Exactly. 00:05:06.560 --> 00:05:09.899 And network time protocol, or NTP, uses an epoch 00:05:09.899 --> 00:05:13.560 of January 1, 1900. But Unix, Unix just picked 00:05:13.560 --> 00:05:16.959 a random Thursday in 1970 for convenience. It's 00:05:16.959 --> 00:05:19.360 hilarious. If we connect this to the bigger picture, 00:05:19.720 --> 00:05:22.040 that completely arbitrary patch made by just 00:05:22.040 --> 00:05:24.759 a few engineers in the 1970s just to stop their 00:05:24.759 --> 00:05:27.180 specific hardware from crashing went on to conquer 00:05:27.180 --> 00:05:29.759 the entire digital world. Because of the C programming 00:05:29.759 --> 00:05:32.220 language. Yes, the C programming language adopted 00:05:32.220 --> 00:05:34.680 it. And because C became the bedrock of modern 00:05:34.680 --> 00:05:37.680 computing, Unix time basically became the default 00:05:37.680 --> 00:05:39.800 timekeeper for almost everything you interact 00:05:39.800 --> 00:05:42.040 with. Which is just staggering when you really 00:05:42.040 --> 00:05:45.540 think about it. It is. Today, Apple's APFS file 00:05:45.540 --> 00:05:47.759 system, the exact code organizing every single 00:05:47.759 --> 00:05:50.600 photo on your iPhone right now, it uses it. Wow. 00:05:50.819 --> 00:05:53.199 Linux's XT4, which runs the servers hosting your 00:05:53.199 --> 00:05:55.930 favorite websites, uses it. Android smartphones, 00:05:56.490 --> 00:05:58.029 JavaScript web applications back in my super 00:05:58.029 --> 00:06:00.730 databases. I mean, they are all at their core, 00:06:01.110 --> 00:06:03.550 just counting the seconds since that convenient 00:06:03.550 --> 00:06:06.410 moment in 1970. It really is staggering that 00:06:06.410 --> 00:06:09.389 something you and I rely on every single day 00:06:09.389 --> 00:06:11.850 started out with duct tape and a kind of this 00:06:11.850 --> 00:06:14.430 seems fine attitude. Yeah, good enough for now. 00:06:14.730 --> 00:06:18.410 Exactly. But a simple stopwatch counting to infinity 00:06:18.410 --> 00:06:21.550 only works flawlessly if every single day is 00:06:21.550 --> 00:06:24.399 mathematically identical. And we know that physical 00:06:24.399 --> 00:06:27.300 reality simply refuses to play by strict mathematical 00:06:27.300 --> 00:06:30.100 rules. Oh, reality is way too messy for that. 00:06:30.300 --> 00:06:32.720 Yeah. To understand the system's biggest headache, 00:06:32.899 --> 00:06:34.740 we have to look at the friction between the machine 00:06:34.740 --> 00:06:37.160 and the physical rotation of the Earth. The Earth's 00:06:37.160 --> 00:06:40.139 wobble, essentially. Yeah. We actually have two 00:06:40.139 --> 00:06:42.079 different standards of time operating in the 00:06:42.079 --> 00:06:44.959 background of our lives. First, there's International 00:06:44.959 --> 00:06:48.660 Atomic Time, or TAI. OK. This is mathematically 00:06:48.660 --> 00:06:51.420 flawless timekeeping. It relies on the absolute 00:06:51.420 --> 00:06:54.019 precision of atomic clocks measuring the vibration 00:06:54.019 --> 00:06:57.519 of atoms. Every single day in TAI is precisely 00:06:57.519 --> 00:07:01.459 86 ,400 seconds long. Yeah. It never, ever wavers. 00:07:01.519 --> 00:07:03.800 Pure unadulterated physics. Pure math. But we 00:07:03.800 --> 00:07:05.939 don't live our daily lives by atomic time, do 00:07:05.939 --> 00:07:08.680 we? We use coordinated universal time, or UTC. 00:07:09.160 --> 00:07:12.660 And UTC is civil time, which means it actually 00:07:12.660 --> 00:07:15.410 cares about solar time. it has to stay aligned 00:07:15.410 --> 00:07:17.430 with the actual position of the Earth relative 00:07:17.430 --> 00:07:19.569 to the Sun. And that's where the problem starts. 00:07:19.829 --> 00:07:21.870 Because the Earth's rotation is slowing down 00:07:21.870 --> 00:07:27.110 very slightly and very unpredictably due to tidal 00:07:27.110 --> 00:07:29.730 friction and other planetary wobbles. Exactly. 00:07:30.089 --> 00:07:32.029 And because the Earth is slowing down, solar 00:07:32.029 --> 00:07:34.290 days are occasionally a tiny bit longer than 00:07:34.290 --> 00:07:37.069 mathematical days. So to keep our clocks aligned 00:07:37.069 --> 00:07:40.170 with the actual sunrise and sunset, the authorities 00:07:40.170 --> 00:07:43.269 who manage UTC Occasionally insert what's called 00:07:43.269 --> 00:07:45.689 a leap second into the calendar. It's basically 00:07:45.689 --> 00:07:48.329 just a random extra second thrown into the global 00:07:48.329 --> 00:07:50.490 timeline every year and a half or so just to 00:07:50.490 --> 00:07:52.670 let the physical Earth catch up with the atomic 00:07:52.670 --> 00:07:55.050 clocks. Now bring that back to our Unix stopwatch. 00:07:55.509 --> 00:07:57.990 According to the POSEX standard, which is essentially 00:07:57.990 --> 00:08:00.009 the foundational rulebook that defines how a 00:08:00.009 --> 00:08:02.870 Unix operating system must behave, Unix time 00:08:02.870 --> 00:08:05.110 strictly enforces that every single day must 00:08:05.110 --> 00:08:09.209 contain exactly 86 ,400 seconds. No more, no 00:08:09.209 --> 00:08:11.829 less. Exactly. No exceptions. So the unstoppable 00:08:11.829 --> 00:08:15.050 force of Unix time meets the immovable of a leap 00:08:15.050 --> 00:08:20.230 second. The UTC clock strikes 23 .59 .60, which 00:08:20.230 --> 00:08:23.129 is that weird extra leap second. The machine 00:08:23.129 --> 00:08:27.029 requires the day to be 86 ,400 seconds, but physical 00:08:27.029 --> 00:08:31.449 reality just handed it a day with 86 ,401 seconds. 00:08:31.610 --> 00:08:33.649 And the system essentially has a mild panic attack 00:08:33.649 --> 00:08:36.210 and executes a hack. A panic attack. Basically, 00:08:36.409 --> 00:08:39.389 yeah. During a positive leap second, Unix time 00:08:39.389 --> 00:08:42.049 actually repeats a timestamp. It counts normally 00:08:42.049 --> 00:08:43.850 up to the very end of the day, and then during 00:08:43.850 --> 00:08:45.889 the leap second, the timestamp just jumps back 00:08:45.889 --> 00:08:48.049 by one second, literally returning to the start 00:08:48.049 --> 00:08:49.669 of the next day. Right, right, right. So for 00:08:49.669 --> 00:08:52.250 one second, the system's time is completely ambiguous. 00:08:52.710 --> 00:08:54.690 It literally repeats the exact same numerical 00:08:54.690 --> 00:08:57.870 timestamp twice. How does a computer know which 00:08:57.870 --> 00:09:00.009 second is the real one if the numbers are identical? 00:09:00.210 --> 00:09:02.289 What's fascinating here is there isn't one universal 00:09:02.289 --> 00:09:04.830 answer. Different computing systems have invented 00:09:04.830 --> 00:09:06.889 completely different ways to panic and try to 00:09:06.889 --> 00:09:09.789 solve this ambiguity. For instance, there's a 00:09:09.789 --> 00:09:12.149 widely used workaround called the Mills -style 00:09:12.149 --> 00:09:15.029 NTKey variant, which is used in network time 00:09:15.029 --> 00:09:18.629 protocol systems. It openly violates those strict 00:09:18.629 --> 00:09:21.809 POSX rulebook constraints just to maintain its 00:09:21.809 --> 00:09:24.129 sanity. He just breaks the rules. Yeah, has to. 00:09:24.389 --> 00:09:26.769 Instead of blindly repeating the number and just 00:09:26.769 --> 00:09:29.669 hoping for the best, it uses hidden state variables 00:09:29.669 --> 00:09:32.649 like little flags buried in the code. It triggers 00:09:32.649 --> 00:09:35.230 a state called timelines when it's inserting 00:09:35.230 --> 00:09:37.909 the leap second, and then it transitions to a 00:09:37.909 --> 00:09:40.389 state called time weight while it actually repeats 00:09:40.389 --> 00:09:43.620 the seconds count. It essentially leaves a breadcrumb 00:09:43.620 --> 00:09:45.460 trail so the computer can look at the background 00:09:45.460 --> 00:09:48.220 code and figure out exactly which of the two 00:09:48.220 --> 00:09:50.440 identical seconds it's currently experiencing. 00:09:50.799 --> 00:09:52.879 So the system is essentially whispering to itself, 00:09:53.179 --> 00:09:55.159 OK, I'm repeating the number now. Don't freak 00:09:55.159 --> 00:09:57.779 out. It's just a leap second. Exactly. But then 00:09:57.779 --> 00:10:00.100 there's a much rarer approach, sometimes called 00:10:00.100 --> 00:10:03.799 the TAI variant. The engineers building these 00:10:03.799 --> 00:10:06.159 systems decided that repeating numbers was simply 00:10:06.159 --> 00:10:08.620 too dangerous for their applications. Understandably 00:10:08.620 --> 00:10:11.669 so. Right, so they completely ignore the POSEX 00:10:11.669 --> 00:10:15.090 86 ,400 second rule. They just count all the 00:10:15.090 --> 00:10:17.250 leap seconds linearly as they happen. They just 00:10:17.250 --> 00:10:20.509 add them in. Yeah. But the severe downside is 00:10:20.509 --> 00:10:22.710 that because they keep counting those extra seconds, 00:10:23.210 --> 00:10:25.789 their internal timestamps slowly drift completely 00:10:25.789 --> 00:10:29.070 out of sync with actual UTC civil time. Which 00:10:29.070 --> 00:10:31.190 means if you try to compare a timestamp from 00:10:31.190 --> 00:10:33.690 a strict UNIX system with a timestamp from one 00:10:33.690 --> 00:10:36.889 of those rare TAI systems, the numbers literally 00:10:36.889 --> 00:10:39.470 won't match. They'll be off by however many leap 00:10:39.470 --> 00:10:41.889 seconds have occurred. A master clock designed 00:10:41.889 --> 00:10:44.629 to keep the entire digital world synchronized 00:10:44.629 --> 00:10:47.429 actually has these deep underlying fault lines 00:10:47.429 --> 00:10:50.490 where time literally breaks or duplicates itself. 00:10:50.590 --> 00:10:52.730 And we haven't even touched the most severe conflict 00:10:52.730 --> 00:10:55.429 yet. We've seen how the rigid math of Unix time 00:10:55.429 --> 00:10:57.429 clashes with the physical rotation of the Earth. 00:10:57.690 --> 00:11:00.149 But there's a second, even more fatal collision 00:11:00.149 --> 00:11:03.210 approaching. The 2038 problem. Yes, the clash 00:11:03.210 --> 00:11:05.750 between this relentlessly ticking clock and the 00:11:05.750 --> 00:11:07.850 physical limits of computer memory itself. This 00:11:07.850 --> 00:11:10.330 brings us right back to our opening hook. The 00:11:10.330 --> 00:11:13.129 machine is simply running out of digits. Because 00:11:13.129 --> 00:11:16.450 for decades, the standard way to store this Unix 00:11:16.450 --> 00:11:19.809 timestamp in a computer's memory was as a 32 00:11:19.809 --> 00:11:22.490 -bit signed integer. Let's break down exactly 00:11:22.490 --> 00:11:24.490 how that works because the math really explains 00:11:24.490 --> 00:11:27.120 the impending crisis here. Sure. A 32 -bit integer 00:11:27.120 --> 00:11:30.200 is basically a digital box with 32 tiny slots 00:11:30.200 --> 00:11:33.440 for ones and zeros, literally 32 microstopic 00:11:33.440 --> 00:11:35.659 light switches turning on or off to represent 00:11:35.659 --> 00:11:38.299 a number in binary code. Right. And because it's 00:11:38.299 --> 00:11:40.120 a signed integer, the computer needs to know 00:11:40.120 --> 00:11:41.940 if the number is positive or negative, which 00:11:41.940 --> 00:11:45.600 is how it handles dates before 1970. So it dedicates 00:11:45.600 --> 00:11:47.820 the very first switch simply to represent the 00:11:47.820 --> 00:11:50.419 plus or minus sign. Leaving exactly 31 switches 00:11:50.419 --> 00:11:53.309 for the number. Yes, that leaves exactly 31 switches 00:11:53.309 --> 00:11:55.610 to hold the actual number of seconds. And if 00:11:55.610 --> 00:11:58.190 you calculate 2 to the power of 31, you find 00:11:58.190 --> 00:12:00.549 the absolute maximum capacity of that digital 00:12:00.549 --> 00:12:03.669 box. It gives you a maximum value of exactly 00:12:03.669 --> 00:12:09.649 2 ,147 ,483 ,647. 2 billion and change. That 00:12:09.649 --> 00:12:12.070 is the absolute largest number of seconds that 00:12:12.070 --> 00:12:14.289 a 32 -bit signed integer can physically hold. 00:12:14.509 --> 00:12:17.429 So if you start counting from January 1st in 00:12:17.429 --> 00:12:20.289 1870, when do you hit that 2 billionth second? 00:12:20.539 --> 00:12:23.820 The source gives us the exact doom date. The 00:12:23.820 --> 00:12:26.279 absolute maximum value will be reached on Tuesday, 00:12:26.500 --> 00:12:32.690 19 January 2038. at exactly 03 .14 .07 UTC. At 00:12:32.690 --> 00:12:36.629 a 03 .14 .08, the system literally runs out of 00:12:36.629 --> 00:12:39.129 room. The mathematical box is entirely full. 00:12:39.210 --> 00:12:41.409 It's just like an old mechanical car odometer. 00:12:41.590 --> 00:12:43.049 You know, you're driving down the highway, the 00:12:43.049 --> 00:12:46.830 odometer hits 999 ,999, and when you drive one 00:12:46.830 --> 00:12:48.730 more mile, the mechanical dials just click over 00:12:48.730 --> 00:12:50.990 and show all zeros. Exactly the same principle. 00:12:51.230 --> 00:12:54.090 Except in a 32 -bit signed integer, because of 00:12:54.090 --> 00:12:55.870 how the binary math is structured, it doesn't 00:12:55.870 --> 00:12:58.730 roll over to zero. The overflow forces that very 00:12:58.730 --> 00:13:01.029 first sign switch to flip from positive to negative. 00:13:01.029 --> 00:13:02.889 Rolls over into the maximum negative number. 00:13:03.210 --> 00:13:06.409 Right. So one second after 3 .14 a .m. on January 00:13:06.409 --> 00:13:09.649 19th, 2038, the computer's clock suddenly believes 00:13:09.649 --> 00:13:12.070 it has time traveled backwards to Friday, 13 00:13:12.070 --> 00:13:14.769 December 1901. Which is famously known in the 00:13:14.769 --> 00:13:17.409 tech world as the year 2038 problem. And the 00:13:17.409 --> 00:13:19.470 real world consequences are severe, especially 00:13:19.470 --> 00:13:22.149 for legacy systems, historical databases and 00:13:22.149 --> 00:13:24.309 embedded hardware. Like stuff we rely on every 00:13:24.309 --> 00:13:27.740 day. Totally. Think about medical devices. power 00:13:27.740 --> 00:13:31.720 grid controllers, or aviation software that were 00:13:31.720 --> 00:13:34.700 built decades ago on 32 -bit architecture and 00:13:34.700 --> 00:13:36.700 simply can't be easily updated over the internet. 00:13:37.100 --> 00:13:39.840 If a database is scheduling an event for 2039 00:13:39.840 --> 00:13:43.460 right now and it's using a 32 -bit Unix timestamp, 00:13:43.700 --> 00:13:45.700 the software thinks that event just got scheduled 00:13:45.700 --> 00:13:50.190 for 1902. If the 32 -slot digital box is completely 00:13:50.190 --> 00:13:52.870 full, I have to assume the only hardware fix 00:13:52.870 --> 00:13:55.789 is to literally build a bigger box. Are they 00:13:55.789 --> 00:13:57.889 just doubling the capacity and moving everyone 00:13:57.889 --> 00:14:00.870 to a 64 -bit integer? The solution is conceptually 00:14:00.870 --> 00:14:03.309 that simple, yes. The industry is widening the 00:14:03.309 --> 00:14:06.330 data type to 64 bits. Practically tracking down 00:14:06.330 --> 00:14:08.769 every single piece of 32 -bit code on Earth and 00:14:08.769 --> 00:14:11.250 replacing it is a monumental task, but the 64 00:14:11.250 --> 00:14:13.500 -bit shift is the definitive cure. Here's where 00:14:13.500 --> 00:14:15.580 it gets really interesting, because adding 32 00:14:15.580 --> 00:14:17.600 extra bits doesn't just double the time limit. 00:14:17.620 --> 00:14:20.240 By adding 32 more binary switches, you expand 00:14:20.240 --> 00:14:22.240 the capacity exponentially. Oh, massively. The 00:14:22.240 --> 00:14:24.460 source notes that shifting to a 64 -bit integer 00:14:24.460 --> 00:14:27.940 expands the calendar range of Unix time to 292 00:14:27.940 --> 00:14:30.659 .3 billion years in both directions. That is 00:14:30.659 --> 00:14:34.460 292 billion years into the future and 292 billion 00:14:34.460 --> 00:14:36.960 years into the past. To put the sheer scale of 00:14:36.960 --> 00:14:39.200 that in perspective for you, the current estimated 00:14:39.200 --> 00:14:42.519 age of the entire universe is about 13 .8 billion 00:14:42.519 --> 00:14:46.080 years. years. A 64 -bit Unix clock can measure 00:14:46.080 --> 00:14:48.580 a timeline that is over 20 times the current 00:14:48.580 --> 00:14:50.679 age of the universe. It's absurd. I think it's 00:14:50.679 --> 00:14:52.600 safe to say the software engineers working in 00:14:52.600 --> 00:14:56.139 the year 292 billion won't have to worry about 00:14:56.139 --> 00:14:59.399 an overflow bug. It is genuinely amusing to think 00:14:59.399 --> 00:15:02.940 of Unix time stretching from the dawn of a future 00:15:02.940 --> 00:15:05.399 universe all the way back to before the Big Bang, 00:15:06.059 --> 00:15:08.639 all centered around a random Thursday in 1970 00:15:08.639 --> 00:15:10.879 that a few guys thought was, you know, convenient. 00:15:11.019 --> 00:15:13.379 The human element in all of this is what truly 00:15:13.379 --> 00:15:15.399 stands out to me, because despite the leap -second 00:15:15.399 --> 00:15:18.460 ambiguities and despite the looming 2038 apocalypse, 00:15:19.200 --> 00:15:21.700 Unix Time's immense popularity has created this 00:15:21.700 --> 00:15:24.399 deeply human subculture. It really has. Programmers 00:15:24.399 --> 00:15:26.779 have actually built traditions around this invisible, 00:15:26.779 --> 00:15:29.419 ticking integer. They throw what are known as 00:15:29.419 --> 00:15:33.240 Time Parties. Time Tea Parties. T -I -M -E underscore 00:15:33.240 --> 00:15:36.559 T. That's the specific data type in the C programming 00:15:36.559 --> 00:15:40.000 language used to define Unix Time. Right, and 00:15:40.000 --> 00:15:42.080 programmers gather to celebrate when the Unix 00:15:42.080 --> 00:15:44.899 stopwatch hits highly satisfying decimal or binary 00:15:44.899 --> 00:15:47.419 numbers. It's exactly like how we celebrate the 00:15:47.419 --> 00:15:49.799 new year on the Gregorian calendar, but instead 00:15:49.799 --> 00:15:51.860 of celebrating a physical trip around the sun, 00:15:52.059 --> 00:15:54.539 they are celebrating a satisfying string of digital 00:15:54.539 --> 00:15:57.059 digits. And the most famous of these global celebrations 00:15:57.059 --> 00:16:00.220 was the Unix Millennium. a portmanteau of billion 00:16:00.220 --> 00:16:02.779 and millennium. This took place on September 00:16:02.779 --> 00:16:09.679 9, 2001 at 01 .46 .40 UTC. That was the exact 00:16:09.679 --> 00:16:12.460 moment the Unix time number ticked over to 1 00:16:12.460 --> 00:16:15.039 million seconds, a perfect one followed by nine 00:16:15.039 --> 00:16:18.019 zeros. And naturally, in true software fashion, 00:16:18.440 --> 00:16:20.879 the celebration arrived alongside a massive wave 00:16:20.879 --> 00:16:23.559 of Of course it did. The source highlights a 00:16:23.559 --> 00:16:25.779 brilliant detail about why the millennium broke 00:16:25.779 --> 00:16:28.299 things. When the timestamp hit a billion, it 00:16:28.299 --> 00:16:31.179 caused sorting errors in certain programs, specifically 00:16:31.179 --> 00:16:33.539 the K -mail email client, which was part of the 00:16:33.539 --> 00:16:35.679 KDE desktop environment. Because of how it read 00:16:35.679 --> 00:16:37.860 the numbers. Exactly. The reason it broke is 00:16:37.860 --> 00:16:39.720 that the program wasn't reading the timestamps 00:16:39.720 --> 00:16:42.299 as pure math, it was storing them as plain text. 00:16:42.639 --> 00:16:45.259 And in a simple text sort, the computer uses 00:16:45.259 --> 00:16:48.259 alphabetical logic rather than numerical value. 00:16:48.379 --> 00:16:50.620 Just like the word Apple comes before banana 00:16:50.620 --> 00:16:53.600 because A comes first in the alphabet, a one 00:16:53.600 --> 00:16:55.960 billion timestamp starting with the text character 00:16:55.960 --> 00:16:58.659 one was erroneously sorted before an older timestamp 00:16:58.659 --> 00:17:01.879 starting with a nine like 999 million. The computer 00:17:01.879 --> 00:17:04.160 saw the one and just threw it to the top of the 00:17:04.160 --> 00:17:06.539 pile. So people's email inboxes suddenly had 00:17:06.539 --> 00:17:08.579 brand new messages buried at the very bottom 00:17:08.579 --> 00:17:11.940 beneath emails from 1999. What a mess. It was 00:17:11.940 --> 00:17:14.039 just a cosmetic bug. It was quickly patched. 00:17:14.059 --> 00:17:16.319 Sure. But it remains a perfect example of what 00:17:16.319 --> 00:17:18.359 happens when a hidden foundation suddenly changes 00:17:18.359 --> 00:17:20.579 its shape. And the celebrations didn't stop in 00:17:20.579 --> 00:17:24.740 2001. On Friday, February 13, 2009, the decimal 00:17:24.740 --> 00:17:30.700 representation of Unix time hit 1 ,234 ,567 ,890 00:17:30.700 --> 00:17:32.859 seconds. A perfect sequence of one through zero. 00:17:33.019 --> 00:17:34.880 People threw parties all over the world for that 00:17:34.880 --> 00:17:37.000 one. Google even celebrated it with a custom 00:17:37.000 --> 00:17:39.440 Google Doodle on their homepage. It really highlights 00:17:39.440 --> 00:17:41.880 our intrinsic need to find patterns, to enforce 00:17:41.880 --> 00:17:44.859 meaning and milestones, even something as dry 00:17:44.859 --> 00:17:47.079 as an operating system's internal hardware counter. 00:17:47.200 --> 00:17:51.359 So what does this all mean? We take a cold, invisible 00:17:51.359 --> 00:17:53.720 integer, this duct tape engineering fix from 00:17:53.720 --> 00:17:56.619 the 70s designed just to stop the machine from 00:17:56.619 --> 00:17:59.900 crashing, and we map our human desire for tradition 00:17:59.900 --> 00:18:03.160 right on top of it. It ceases to be just a piece 00:18:03.160 --> 00:18:05.539 of code at that point. It elevates into a cultural 00:18:05.539 --> 00:18:07.839 artifact. And that brings us directly back to 00:18:07.839 --> 00:18:10.720 you listening to this deep dive, because this 00:18:10.720 --> 00:18:13.160 cultural artifact is sitting in your pocket right 00:18:13.160 --> 00:18:15.720 now. Yep, and your phone, your laptop. Every 00:18:15.720 --> 00:18:17.940 time you save a photo to your camera roll, every 00:18:17.940 --> 00:18:19.819 time you send a text message, every time you 00:18:19.819 --> 00:18:22.420 load a web page on a server, your digital life 00:18:22.420 --> 00:18:25.420 is being synchronized by this slightly flawed, 00:18:25.880 --> 00:18:29.440 endlessly fascinating stopwatch from 1970. It 00:18:29.440 --> 00:18:31.619 repeats itself during leap seconds. It threatens 00:18:31.619 --> 00:18:34.599 to break legacy computers in 2038, but it is 00:18:34.599 --> 00:18:37.019 still ticking. And with the shift to 64 -bit 00:18:37.019 --> 00:18:40.019 architecture, it may be ticking for a very, very 00:18:40.019 --> 00:18:42.019 long time. Actually, the source material mentions 00:18:42.019 --> 00:18:44.660 a brilliant concept exploration of this from 00:18:44.660 --> 00:18:47.240 a science fiction novel by Werner Wienge called 00:18:47.240 --> 00:18:49.539 A Deepness in the Sky. Oh, I loved this part. 00:18:49.740 --> 00:18:51.839 The scale of this concept is absolutely mind 00:18:51.839 --> 00:18:55.259 -bending. It really is. In the novel, Wienge 00:18:55.259 --> 00:18:58.099 imagines a space -faring human civilization thousands 00:18:58.099 --> 00:19:00.539 of years in the future. They're traveling between 00:19:00.539 --> 00:19:03.039 stars, trading across galaxies, operating on 00:19:03.039 --> 00:19:05.140 a scale we can barely even comprehend. Right. 00:19:05.309 --> 00:19:07.809 Yet the baseline calendar they use to synchronize 00:19:07.809 --> 00:19:09.930 all their advanced computer systems across the 00:19:09.930 --> 00:19:13.950 galaxy is still the Unix epoch. A 1970s operating 00:19:13.950 --> 00:19:16.789 system clock running a galactic empire. Exactly. 00:19:17.230 --> 00:19:19.990 And in this future society, there is a specialized 00:19:19.990 --> 00:19:22.730 class of workers called programmer archaeologists. 00:19:23.690 --> 00:19:26.390 Their entire job is to dig through layers of 00:19:26.390 --> 00:19:29.250 ancient, mature computer code to keep the civilization 00:19:29.250 --> 00:19:31.529 running. Digging through the digital dirt. Yeah. 00:19:31.640 --> 00:19:33.660 And when these future archaeologists look at 00:19:33.660 --> 00:19:36.099 this foundational epoch, the zero date that their 00:19:36.099 --> 00:19:39.000 entire civilization relies on, they naturally 00:19:39.000 --> 00:19:41.900 assume it must honor something monumental. They 00:19:41.900 --> 00:19:44.339 hypothesize that the zero date marks the exact 00:19:44.339 --> 00:19:46.200 moment when a human first walked on the moon. 00:19:46.839 --> 00:19:48.460 Because what else could possibly be important 00:19:48.460 --> 00:19:50.859 enough to synchronize the stars to, right? Right. 00:19:51.319 --> 00:19:53.380 But as they dig deeper into the ancient code, 00:19:53.759 --> 00:19:57.299 they realize the mundane truth. It isn't a monument 00:19:57.299 --> 00:20:00.299 to human achievement at all. It's just the zero 00:20:00.299 --> 00:20:03.440 second of a primordial 1970s operating system. 00:20:03.700 --> 00:20:06.220 Picked by a few forgotten engineers entirely 00:20:06.220 --> 00:20:08.779 for convenience. This raises an important question. 00:20:08.859 --> 00:20:12.180 It really does. Could a completely arbitrary 00:20:12.180 --> 00:20:14.920 date, picked merely to stop an old piece of hardware 00:20:14.920 --> 00:20:17.819 from crashing, actually outlive the Gregorian 00:20:17.819 --> 00:20:21.180 calendar? Could the Unix epoch become the permanent, 00:20:21.460 --> 00:20:24.440 unchangeable baseline for humanity's future among 00:20:24.440 --> 00:20:26.420 the stars? I mean, when you upgrade a system 00:20:26.420 --> 00:20:29.099 to an integer that can seamlessly count seconds 00:20:29.099 --> 00:20:32.640 for 292 billion years, there is incredibly little 00:20:32.640 --> 00:20:35.119 incentive to ever change it. It's definitely 00:20:35.119 --> 00:20:37.339 something to think about the next time your phone 00:20:37.339 --> 00:20:39.650 time stamps a text message or your computer sorts 00:20:39.650 --> 00:20:42.029 of file. The stopwatch is running and it's taking 00:20:42.029 --> 00:20:44.450 us all the way to the end of the universe. Thank 00:20:44.450 --> 00:20:46.430 you so much for joining us on this deep dive 00:20:46.430 --> 00:20:48.529 into the ticking heart of your technology. Until 00:20:48.529 --> 00:20:50.769 next time, keep questioning the numbers behind 00:20:50.769 --> 00:20:51.170 the screen.