Time

• Day 19: Leap Seconds or When a Minute Has 61

  It’s week four and this week we’re talking about the inconsistencies, the problems, the strange things about time and how we measure it. If week three was mostly about software and computer systems, week four is more about the properties or the features or the details of recording time and our time systems.

  The first crack in our concept of time is the quite irregular leap second.

  ---

  UTC works?

  How can a minute ever have 61 seconds? If you start at zero, you got to end at 59. You start at zero and you end at 60, now you have 61 seconds. That doesn’t make sense.

  If you have ever seen :60Z in a log file, that is the leap second. That minute had sixty-one seconds in it.

  It exists because we are trying to do the impossible: keep two completely different definitions of the “second” in alignment, forever. There are, it turns out, two definitions.

  But wait, it gets worse.

  There are three time scales running in the background of our civilization right now:

  • TAI, or International Atomic Time. The average of about 400 atomic clocks at standards labs around the world, all ticking off the cesium hyperfine transition we covered on Day 8. TAI is uniform. Every second is the same length as every other second. TAI does not care about the Earth.
  • UT1, or Universal Time 1. Defined by the Earth’s actual rotation, measured by tracking distant quasars with radio telescopes. UT1 is wobbly. The Earth speeds up and slows down by milliseconds per day, mostly because of tidal friction (slowing it down) and core-mantle coupling (anyone’s guess on any given decade).
  • UTC, or Coordinated Universal Time. The civil time on your phone. UTC is TAI minus an integer number of leap seconds, kept within 0.9 seconds of UT1.

  It’s time to stop pretending like the current version of UTC isn’t a compromise. It certainly is not the best we could come up with. It’s just what everyone could agree on.

  The first of its problems is the dang leap second.

  ---

  So how did we get to this mess?

  The IERS, the International Earth Rotation and Reference Systems Service in Paris, watches the gap between UT1 and UTC. They announce the leap second six months in advance in an actual notice called Bulletin C. They also have their own weekly and monthly newsletters called Bulletin A and Bulletin B. I don’t know what is going on at IERS and I’m sorry to anyone working there, but this leap second thing is kinda crazy.

  When the leap happens, the clock reads:

  23:59:58
  23:59:59
  23:59:60   ← this is the leap second
  00:00:00
  

  That :60 is the part that breaks software. Most date/time libraries do not believe :60 is a real value. POSIX, the standard governing Unix systems, explicitly defines Unix time to pretend leap seconds don’t exist.

  Since the system was introduced in 1972, 27 leap seconds have been inserted, although none since 2016. Also, there has never been a negative leap second. We’ve only ever needed to slow UTC down to match the Earth.

  But, that may be about to change. More on that tomorrow.

  Because I can’t help myself.

  ---

  Here’s more stuff about… Computers.

  There are three ways a computer can handle the leap second arriving.

  1. Step. At midnight, the clock just jumps back one second. From the OS’s perspective, time briefly moves backward. Anything assuming time is monotonic, meaning it only goes forward, sees its assumption violated and may explode.
  2. Stall. Hold 23:59:59 for two seconds. Time doesn’t go backward, but two events get the same timestamp. Anything depending on timestamp uniqueness gets confused.
  3. Smear. Spread the extra second over a long window (Google originally used 20 hours centered on the leap, then standardized at 24 hours) by ticking slightly slow for the whole period. No :60 ever appears. No backward step. Just a clock that runs 1.0000116× slow for a day.

  Google introduced smearing in 2008. By the late 2010s most cloud providers (Amazon, Microsoft, Facebook) had adopted some flavor. It is now the de facto practice.

  Before smearing, leap seconds were MORE dangerous.

  ---

  A second is a second not two

  A leap second is like when Pluto was a Planet. It has to be a singular definition. A known amount. A standard. Software written at some of the most capable engineering organizations still took down important infrastructure, internet infrastructure. Clearly it should not be this hard to define a unit of time.

  But anyways, onto the next post.

  Tomorrow will cover the historic 2022 vote to abolish the leap second, the fight that produced it, and what we all agreed to.

  ---

  Sources

  • International Earth Rotation and Reference Systems Service (IERS) — The body responsible for monitoring Earth’s rotation and issuing Bulletin C to announce leap seconds.
  • A global timekeeping problem postponed by global warming — Nature (2024). The Duncan Agnew paper detailing how melting polar ice has counteracted the Earth’s acceleration, delaying the unprecedented “negative leap second” until roughly 2029.
  • POSIX.1-2017 Base Definitions: Seconds Since the Epoch — The Open Group. The formal specification demonstrating that Unix time legally ignores leap seconds.
  • Time, Technology and Leaping Seconds — Google’s original 2011 blog post introducing the concept of the “leap smear.”
  • The Leap Second Glitch Explained — Wired. Detailed breakdown of the 2012 Linux hrtimer bug that took down Reddit and Qantas.
  • How and why the leap second affected Cloudflare DNS — Cloudflare’s excellent, candid post-mortem of their 2017 New Year’s RRDNS outage.

  I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

  Jun 11, 2026 Programming Infrastructure Time 30daysoftime Leap-second UTC

  Enjoyed this?

• Day 18: DST and The Related Software Bugs

  This is one of two or three DST posts in the 30 Days of Time series. Today’s angle: the software bugs.

  Twice a year, in most of the developed world, the clocks jump forward in spring and back in fall. The hour that doesn’t exist in spring materializes and then disappears in the fall. This is the source of more shipped bugs than any other single phenomenon in software.

  ---

  The Two Impossible Hours

  The mechanics, if you’ve never thought hard about them.

  Spring forward. On the transition Sunday in March (in the US), the clock reads 01:59:59 and then immediately reads 03:00:00. The hour from 2:00 to 2:59 AM does not exist. 2:30 AM on that day is not a time. If you tell a computer to do something at 2:30 AM on that day, you have asked it to do something at a time that doesn’t exist.

  What it does is up to the library:

  • It might silently skip.
  • It might silently run at 3:30 instead.
  • It might throw an exception.
  • It might run at the wrong time and silently throw your reports off.

  The classic landmine is a daily task scheduled in local time, for example a job set to run at 1:30 AM. If you’re using the standard Linux cron daemon, it has battle-tested, built-in logic to detect DST transitions and prevent duplicates.

  The problems are usually at the application layer. If you are using an application-level scheduler or Cron library that hasn’t been configured properly and blindly trusts the system clock, you can get into a situation where that 1:30 a.m. doesn’t exist or runs twice.

  ---

  A Short Tour of Named Disasters

  March 2007, United States. Congress passed the Energy Policy Act of 2005, which moved DST to begin three weeks earlier and end one week later. The change took effect in March 2007. Every system in the country running on a tz database older than mid-2006 spent three weeks in March, and one week in November, off by an hour. Banks ran payroll at the wrong time. BlackBerry calendars showed every meeting an hour off. Federal agencies had to issue advisories. The DOE later estimated the extension saved about 0.5% of electricity per day of extended DST, or roughly 1.3 TWh annually. The remediation cost across every affected piece of software in the country dwarfed that figure. (More on that later.)

  New Year 2011, iOS. Non-recurring alarms set for January 1 or 2, 2011 did not fire, in any time zone. People slept through work. Apple’s official advice was to set one-time alarms as recurring until January 3. This was on top of an iOS DST bug from a few months earlier, when the fall 2010 transition shifted alarms by an hour in countries that had already changed clocks. Two months after the New Year’s bug, iOS again mis-handled the US spring DST transition. Apple released an apologetic fix and quietly rewrote the alarm subsystem.

  Brazil, April 2019. Brazil canceled DST after decades of observing it, via Decree 9,764. This is fine for clocks going forward, but the cancellation was announced only a few months in advance, and the IANA tz database had to ship updates fast. Every Brazilian server running on a stale cache spent the next year an hour off, in particular for any future-scheduled event saved as “local time.”

  Palestine. For about a decade running, Google Calendar shipped wrong DST data for Palestine, because the Palestinian Authority changes DST rules with short notice and the IANA volunteers don’t always learn in time. Meetings between Israeli and Palestinian colleagues would silently shift by an hour twice a year.

  ---

  The Shape of the Failure

  The DST bugs usually go like this:

  1. A piece of software was written with the assumption that local time is well-defined and monotonic.
  2. Local time is neither.
  3. The author never hit edge cases. It only happens twice a year, in certain regions, under certain settings.
  4. The bug ships. It runs fine for six months. Then it doesn’t.

  The mitigations are well-known and this is why we do what we do.

  • Store UTC. Always. The IANA zone ID goes in a separate column. Never, ever store a naked local timestamp.
  • Recompute the local display every time. Treat local-time as a view, not data.
  • Never schedule anything between 2 and 3 AM local. That hour does not exist in your country half the time.
  • Use libraries that surface the ambiguity. The older Python pytz library would throw when you constructed an impossible local time. The modern zoneinfo handles it silently via a fold attribute, meaning you have to manually check for ambiguity. JavaScript’s Date produces inconsistent results across engines. The Temporal API, which reached Stage 4 in March 2026 and ships in Chrome 144, Firefox 139, and Node 26, lets you explicitly reject ambiguous times. Use it the soonest you can.
  • Keep tzdata current. This is a system-package problem and most teams forget about it until something breaks.

  The tricky part of software has always been that we think that the wall clock or the wall time, the number you see on a daily basis is the same as the actual physical passage of time when in reality they are not. Daylight savings time is a really great example of the absurdity of our timekeeping.

  ---

  Week 3 Recap

  If this is the first time you are reading this series I figured a recap is order. Week 3 has been about the infrastructure of practical timekeeping, the layer where computers, calendars, and humans actually have to agree on what time it is.

  • Day 13: Unix Time, 1,780,620,532 — The 10-digit integer counting up from 1970 that runs every computer on Earth, and the weird properties hiding behind the name.
  • Day 14: The Bug That Didn’t End the World, and the One That Still Might — Y2K was a save, not a hoax, and Y2038 is the one nobody is preparing for.
  • Day 15: The Man Who Synchronized the World — David Mills, NTP, and the forty-year project that keeps every networked clock on Earth within a few milliseconds of UTC.
  • Day 16: How the World Agreed on a Date Format (Except the US) — The century-long campaign that produced 2026-06-08T14:30:00Z, and why a bare 05/06/26 is still an act of faith.
  • Day 17: Time Zones Are a Nightmare — 38 named offsets in active use, half-hour zones, and why “what time is it there?” is the wrong question.
  • Day 18 (today): DST, and the bugs that ride along with it twice a year.

  The picture I want to leave you with is that every problem we’ve covered in Week 3 is a downstream consequence of a deeper one. The system isn’t fragile because of bad programmers. It’s fragile because the underlying thing, “what time is it, here, right now,” was never a single answer, and we’ve been pretending it was.

  ---

  What’s Coming

  Week 4 is about the cracks. What if a minute had 61 seconds? What if October had only 21 days? What if every meeting on every calendar landed on the same weekday, forever? Each of those has actually happened, or is being voted on, or was almost adopted. Week 4 covers leap seconds and their abolition, the DST fight nobody can win, and the calendars we use, almost used, and may yet use.

  ---

  Sources

  • Energy Policy Act of 2005 (Wikipedia). Details the US DST schedule change that took effect in 2007.
  • Impact of Extended Daylight Saving Time on National Energy Consumption (US DOE). The 0.5%-per-day savings estimate from the post-2007 study.
  • Apple confirms New Year’s alarm bug (AppleInsider). Coverage of the iOS 2011 non-recurring alarm bug and Apple’s workaround.
  • Daylight saving time in Brazil (Wikipedia). History of DST in Brazil, including the 2019 abolition via Decree 9,764.
  • Zune 30GB leap year bug (Wikipedia). The firmware loop that bricked Zunes on New Year’s Eve 2008.
  • 2012 Reddit leap second outage (Wired). Write-up on the Linux hrtimer bug that took down Reddit, LinkedIn, and Qantas.
  • TC39 Advances Temporal to Stage 4 (Socket). Current status of the JavaScript Temporal API.

  I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

  Jun 10, 2026 Programming Time 30daysoftime Dst Software bugs

  Enjoyed this?

• Day 17 — Time Zones Are a Nightmare

  Yesterday I wrote about how 2026-05-24T14:30:00Z won the format wars. That Z at the end, it turns out, is quite important. It says Zulu, it says UTC, it says: I am refusing to participate in the nightmare that is Timezones.

  However, today we participate.

  ---

  The lie you were told in school

  There are 24 time zones, one for every hour, neat 15° slices of the globe.

  There are not. There are at least 38 named offsets in active use right now, and the list changes a few times a year.

  Some of them are not on the hour:

  • India is at UTC+5:30. The whole country, one zone, half-hour offset.
  • Nepal is at UTC+5:45. Forty-five minutes. Because Nepal decided in 1986 that it wanted its civil time anchored to the meridian passing through Gauri Shankar, not Delhi.
  • Newfoundland is at UTC−3:30.
  • The Chatham Islands are at UTC+12:45.

  The range isn’t 24 hours either. It runs from UTC−12 to UTC+14, a 26-hour spread, because Kiribati got tired of being split by the international date line in 1995 and just moved the line. One day the Line Islands woke up and it was tomorrow.

  Then there’s China, which geographically spans five time zones and politically uses one (UTC+8), so in the far west of Xinjiang the sun rises at what the clock insists is 10 AM. North Korea changed its offset twice in the 2010s, from UTC+9 to UTC+8:30 in 2015 to mark liberation from Japan, then back to UTC+9 in 2018 to align with Seoul during a diplomatic thaw.

  Time zones are not geography. Time zones are politics with a clock face glued to the front.

  ---

  How we got here

  Before about 1850, every town in the world ran on its own clock. Noon was when the sun was overhead here, which meant noon in Boston was several minutes off from noon in New York, which was off from Philadelphia, which was off from everywhere.

  Nobody cared, because nobody was traveling fast enough for it to matter.

  Then the railroads showed up.

  When your train leaves at “noon” and arrives at “3 PM” and every station defines noon differently, you can’t print a schedule. Britain rolled out Railway Time (GMT everywhere) in the 1840s. The American railroads, bless them, didn’t wait for permission. On November 18, 1883, they unilaterally divided the United States into four zones. Newspapers called it “the day of two noons” because clocks across the country jumped, sometimes forward, sometimes back, to land on the new shared time.

  The following year, in October 1884, twenty-five countries met in Washington for the International Meridian Conference and made it official. Greenwich is 0°, the universal day starts at midnight in Greenwich, every other place is some offset from that.

  France abstained. France wanted Paris. France held out until 1911.

  ---

  The “database” holding the world together

  When your phone shows you the right time after you land in Tokyo, when your calendar correctly reschedules a meeting because Mexico canceled DST a few years ago, when your server logs all line up across a deploy in three continents, that all happens because of a single, voluntarily maintained text file.

  It’s called the IANA Time Zone Database, also known as the Olson Database, after Arthur David Olson, an NIH employee who started maintaining it in 1986 as a side project. Today it lives under IANA stewardship and is primarily maintained by Paul Eggert, a UCLA computer scientist who has been doing this, mostly alone, for decades.

  Every Unix system, every Linux distro, every Mac, every iPhone, every Android phone, Java, Python, Go, Rust, Postgres, browsers, every piece of software that knows what time it is, gets its time zone rules from this database. The release cadence is multiple updates per year, almost always triggered by some country’s parliament deciding to change DST rules with three months’ notice.

  The format is something like America/New_York, Europe/Berlin, Asia/Kolkata, Pacific/Kiritimati. Area, slash, location. Not EST, not GMT+5, because those are offsets and offsets aren’t enough. The rules are what you need, because the rules change with politics.

  The whole arrangement is held together by a small group of volunteers, a mailing list, and Paul Eggert’s continued willingness to keep doing this. If he ever stops, somebody else will have to start.

  ---

  Why this is one of the hardest problems in working programmer software

  A few categories of pain, none of them solvable, all of them shipped to production daily:

  1. Ambiguous local times. When the clocks fall back in November, the hour from 1:00 to 2:00 AM happens twice. If a user schedules a meeting at “01:30 local time” on the wrong day, which 01:30 do they mean? There is no correct answer. Your software picks one and someone shows up an hour off.

  2. Nonexistent local times. When the clocks spring forward in March, 2:30 AM doesn’t exist. If somebody’s medication-reminder app is set for 02:30, what does it do that morning? Skip? Run at 03:30? Run at 01:30 the previous hour? There is no correct answer.

  3. Future timestamps are mutable. If you store a meeting as “October 15, 2027 at 3 PM in Mexico City,” and Mexico cancels DST between now and then, which it did, in 2022, the meeting moves. The number of hours from now until that meeting changes after you saved it. The cardinal rule, the only thing that saves you, is this: store UTC and the IANA zone name separately, never store a local timestamp alone, and recompute on display.

  4. JavaScript’s Date object. It’s not great but I worte more about it here, There is a fix called the JavaScript Temporal API. It’s technically here now, though browser support is still rolling out, and we will all be happier when it’s fully supported everywhere.

  ---

  The list of lies (about time)

  There’s a famous post called Falsehoods Programmers Believe About Time, and a partial sample from the time-zone section gives you the texture:

  • “There are 24 time zones.” (38+, give or take, depending on the week.)
  • “A day is 24 hours.” (DST transitions make some days 23 or 25.)
  • “Time zones don’t change.” (They change several times a year.)
  • “If I store the UTC offset I don’t need the zone ID.” (You do, for any future date.)
  • “UTC is a time zone.” (UTC is a time scale. Zones are offsets from it. This distinction is going to matter more than it sounds like it should.)

  All are gotchas that programmers encounter when working with time zones.

  ---

  The ultimate example of technical debt

  The time zone system isn’t broken, per say… it’s working exactly as designed.

  It was designed by railroad executives in 1883, ratified by diplomats in 1884, and then handed off to every country on Earth to amend at will. Every president who has ever moved a DST date for political reasons, every dictator who has ever changed the national offset to flatter a neighbor, every parliament that has voted to abolish daylight saving without specifying when, has added their fingerprint to the IANA database.

  It is a working international system. It is also a Rube Goldberg machine running on a tar pit, held aloft by Paul Eggert and a mailing list.

  If you ever thought Timezones were bad, tomorrow it gets worse. We’re going to talk about Daylight Saving Time, and the specific, named software disasters it has caused.

  ---

  Sources

  • Nepal Standard Time — Wikipedia. Details Nepal’s 1986 decision to anchor civil time to the Gauri Shankar meridian (UTC+5:45).
  • Time in Kiribati — Wikipedia. Covers the 1995 shift of the International Date Line, creating the 26-hour global spread.
  • Time in North Korea — Wikipedia. Documents the geopolitical shifts between UTC+8:30 and UTC+9.
  • Day of Two Noons — Wikipedia. History of American railroads unilaterally standardizing time on November 18, 1883.
  • International Meridian Conference — Wikipedia. The 1884 agreement that established Greenwich as 0° (and France’s holdout until 1911).
  • IANA Time Zone Database — Wikipedia. History of the Olson database, its maintenance by Arthur David Olson and Paul Eggert, and its fundamental role in modern computing.
  • Daylight saving time in Mexico — Wikipedia. Details the national abolishment of DST in October 2022.
  • JavaScript Temporal API — TC39 Documentation. The modern fix for JavaScript’s notoriously broken Date object (currently rolling out to browsers).
  • Falsehoods Programmers Believe About Time — Noah Sussman’s canonical post detailing the myriad ways developers misunderstand time.

  I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

  Jun 9, 2026 Programming History Time 30daysoftime Software

  Enjoyed this?

• Day 14: The Bug That Didn't End the World, and the One That Still Might

  On December 31, 1999, a measurable percentage of the developed world stockpiled bottled water, withdrew cash from ATMs, and stayed up to see if the lights would go out at midnight.

  They didn’t. Planes did not fall from the sky. Power grids did not collapse. Bank balances did not reset. The new millennium arrived, the champagne was opened, and by January 3rd everyone agreed it had been a hoax.

  It was not a hoax. It was a save.

  Y2K was a global $300+ billion engineering effort spread across roughly five years and almost every government and Fortune 500 IT department on Earth. The reason nothing happened on January 1, 2000 is that for half a decade, an enormous number of people worked very hard so that nothing would happen. The bug was real. The fix worked. Most people forgot it was ever a problem.

  Twelve years from now, a structurally identical bug detonates again, but first let’s understand what happened in ‘99.

  Y2K: the bug

  The Y2K bug is almost embarrassingly simple. From the 1960s through the 1980s, computer storage was expensive enough that programmers had a habit of representing years with two digits, 99 instead of 1999, 73 instead of 1973. It saved two bytes per date. Across a payroll system tracking millions of employees, that mattered.

  The assumption baked into that decision was: we’ll have rewritten this system long before the century rolls over.

  This is the most consistently wrong assumption in software engineering. Code outlives its authors’ confidence. By the late 1990s, vast amounts of critical infrastructure, bank ledgers, airline reservation systems, hospital records, utility billing, social security disbursement, military logistics, nuclear plant monitoring, were running on COBOL programs from the 60s and 70s that had been patched but never rewritten. The language is unfamiliar to many but the fix it later approach is relable to everyone. The developers at the time all quietly assumed that the year 99 was less than the year 00.

  When the rollover hit, 99-12-31 + 1 day = 00-01-01 looked, mathematically, like jumping back to 1900. Interest calculations would compute negative ages. Pensioners would suddenly be billed for a century of debt. Reservation systems would mark every upcoming flight as having departed in the past. Insurance policies would expire en masse.

  The reason planes did not fall is that, starting roughly in 1995, every major airline, manufacturer, FAA system, and air traffic controller began an exhaustive audit-and-fix campaign.

  The reason the power grid did not collapse is that every utility company in North America and Europe ran the same campaign on their SCADA systems.

  The reason your bank balance was still correct on January 1, 2000 is that someone, somewhere, spent late nights in 1997 reading printouts of code written before they were born.

  The estimated total global cost: $300 to $600 billion. The amount of measurable damage on January 1, 2000: small enough that people argued for the next decade about whether the spend had been justified.

  It was. The bug was real. The fix worked. The result of a successful preventive engineering campaign is that it looks, in retrospect, like the problem was never there.

  Y2038: the same bug, different number

  Twelve years from now, specifically, January 19, 2038, at 03:14:07 UTC, a structurally identical bug fires for a different reason.

  Unix time is stored, on a huge amount of legacy infrastructure, as a signed 32-bit integer. That gives you about 2.1 billion seconds of positive range from the 1970 epoch. 2.1 billion seconds is 68 years. 1970 + 68 = 2038.

  At 03:14:07 UTC on that date, the counter hits its maximum value, 2,147,483,647. The next tick overflows. In two’s-complement signed integer arithmetic, the value rolls over to its most negative possible value: -2,147,483,648. Interpreted as a Unix timestamp, that’s December 13, 1901.

  Every 32-bit Unix-derived system that hasn’t been patched will, in the span of one tick, conclude that it is now the early 20th century. The effects are the same family of effects as Y2K, but applied to a much wider deployment surface.

  File modification times become nonsensical. SSL certificates appear expired, or worse, not-yet-valid. NTP synchronization fails. Filesystems with 32-bit inode timestamps lose ordering. Embedded device firmware that schedules tasks based on wall-clock time begins executing at random intervals. Industrial control systems that latch state machines on “time since last event” calculations latch on negative durations and either freeze or behave unpredictably.

  Modern desktop and server operating systems are mostly fine. Linux finished migrating to 64-bit time_t on all architectures by kernel 5.6 (2020) and glibc 2.32. macOS and Windows have been 64-bit-clean for over a decade. AWS, GCP, and Azure all run 64-bit kernels.

  The problem is not where you are reading this. The problem is in the physical world that keeps everything running.

  The long tail is enormous

  Estimates of the number of currently deployed 32-bit embedded devices that interact with time_t in some way range from a few hundred million to several billion.

  Industrial controllers, automotive ECUs, network routers, smart-meter firmware, point-of-sale terminals, medical imaging devices, GPS units, cable boxes, elevator controllers, traffic light systems, ATM internals, payment terminals, building HVAC, water-treatment SCADA, satellite firmware, oil rig control systems, and the embedded computer in your refrigerator.

  Each one, depending on vintage and vendor, may or may not have been patched.

  Many of these devices are not internet-connected and cannot be patched remotely. Many are running firmware whose source code has been lost. Many are running firmware whose vendor no longer exists. Many are in places where physical access is hard, a deep-sea oil platform, a satellite in geostationary orbit, a controller welded inside an industrial machine.

  The Y2K fix worked because the affected systems were largely centralized: mainframes in data centers, software at named companies, code with active maintainers. You could audit it. You could rewrite it. You could ship a patch.

  Y2038 is decentralized. The affected systems are everywhere.

  The Buff Must Flow

  In 2022, Microsoft Exchange Server stopped delivering email worldwide. The cause was a 32-bit signed integer in Exchange’s anti-malware scanner that stored the date as a long-form number. On New Year’s Day, the value tipped over the limit and the scanner refused to load. Mail queues backed up everywhere. Microsoft shipped an emergency script the next day. They called it Y2K22.

  On April 6, 2019, the GPS week number counter rolled over. The failure mode was familiar, an integer designed when the engineers thought it was going to be big enough turned out, decades later, not to be. NYC’s municipal wireless network went down. KLM grounded a flight. Older car and marine GPS units showed dates in 1999.

  Two examples of overflows hitting production and breaking real things. Y2038 will be every one of those at once, in places nobody is thinking about.

  Y2038 is foreseeable. We know about it. We know what needs to be done. We have twelve years. We should get started sooner rather than later. A lot of important systems need to be replaced, and the fewer that fall through the cracks, the better.

  There’s no checklist for the devices we’ve already forgotten about, but maybe there should be.

  ---

  Tomorrow: The Smear, how Google, Amazon, and Meta quietly decided to stop telling the truth about leap seconds, and why everyone else followed.

  Sources

  • Year 2000 problem — Wikipedia
  • Year 2038 problem — Wikipedia
  • Microsoft Exchange year 2022 bug in FIP-FS breaks email delivery — BleepingComputer
  • Microsoft Exchange Fixes Disruptive ‘Y2K22’ Bug — BankInfoSecurity
  • GPS week number rollover — Wikipedia
  • GPS Week Number Rollover — GPS.gov
  • The impact and resolution of the GPS week number rollover of April 2019 — Geoscientific Instrumentation (Copernicus)
  • Linux kernel 5.6 — 64-bit time_t support for 32-bit architectures (KernelNewbies)
  • The Open Group Base Specifications: time.h

  I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

  Jun 6, 2026 Programming History Time 30daysoftime Unix

  Enjoyed this?

• Day 13: Unix Time, 1,780,620,532

  That’s roughly what time it is, right now, as I type this.

  Not 8:48 PM. Not “Thursday.” Not “June 4th, 2026.” None of those are what your computer thinks “now” is. To your laptop, your phone, your car’s infotainment system, the streaming server pushing this page to your browser, and the ATM in the corner store, now is a number. A 10-digit integer. Counting up, one tick per second, since a fixed moment in 1970.

  That number runs the world. It’s the closest thing the global computing infrastructure has to a heartbeat. And it has some weird properties, almost none of which are explained by the name it goes by.

  Unix time.

  The clock under every clock

  Open a terminal. Type date +%s. You’ll see something like 1780620532 come back. That’s Unix time. Seconds since the Unix epoch, 1970-01-01T00:00:00 UTC.

  Every modern operating system tracks time this way internally, even if it dresses up the output for you. The pretty “8:48 PM” on your menu bar is a calculation: take the current Unix timestamp, apply your timezone offset, run it through the calendar rules, format it for display. The underlying number is just 1,780,620,532-and-change, counting up.

  JavaScript’s Date.now()? Unix time in milliseconds. Java’s System.currentTimeMillis()? Unix time in milliseconds. Python’s time.time()? Unix time as a float. Go’s time.Now().Unix()? Unix time. PostgreSQL’s EXTRACT(epoch FROM ...)? Unix time. SQLite’s strftime('%s', 'now')? Unix time.

  It’s the lingua franca of computing. Two systems written in different languages, on different continents, with different calendars in their UIs, agree about what now means because they both agree about this one number.

  Why 1970?

  The honest answer is: convenience.

  In the early 1970s, Ken Thompson and Dennis Ritchie were building Unix at Bell Labs. They needed a way to represent time on a 32-bit machine. Their first attempt counted 1/60 of a second per tick in a 32-bit integer, and overflowed in about two and a half years. So they switched to 1 tick per second, which gave them roughly 136 years of range in a signed 32-bit integer.

  Then they needed a zero. They picked 1970-01-01 because:

  1. It was recent enough that the historical calendar mess (Julian vs. Gregorian, the dropped days in 1582, the year that started in March) was someone else’s problem.
  2. It was round.
  3. It predated every Unix system anyone cared to represent.
  4. It was conveniently close to UTC’s formalization a couple of years later.

  That’s it. There’s no cosmological significance to 1970-01-01. It’s not aligned with any astronomical event. It’s the timestamp equivalent of git init. We’ll start counting from here, and we’ll figure the rest out later.

  The “later” turned out to mean everywhere.

  The thing that isn’t there: leap seconds

  The computer’s time problem mostly comes from UTC.

  Unix time is defined as the number of seconds since the Unix epoch. You might reasonably assume that if I have two timestamps, the difference between them is the actual number of physical seconds that elapsed between those two moments.

  It is not.

  Unix time does not count leap seconds. Since 1972, the IERS has inserted 27 leap seconds into UTC, extra seconds added to keep civil time aligned with Earth’s slowing rotation. Unix time pretends they never happened. The Unix clock has, over its 56-year lifetime, “lost” almost half a minute relative to reality.

  Even weirder: during the actual leap second, when UTC ticks 23:59:59 → 23:59:60 → 00:00:00, Unix time has to do something. POSIX doesn’t specify what. So implementations have invented three different answers:

  1. Repeat the second. The clock shows 23:59:59 for two real seconds and then jumps to 00:00:00. Two distinct physical moments share the same timestamp. File mtimes can collide, log entries can appear out of order.
  2. Insert the second. The clock briefly shows 23:59:60, which is a valid UTC string but breaks every parser that assumes seconds run 00–59. Linux kernels do this. Hilarity ensues at midnight.
  3. Smear it. Don’t insert the second at all. Slow every clock down by a tiny fraction over a 24-hour window so it absorbs the missing second smoothly. Google does this. Amazon does it. Facebook does it.

  So “Unix time” in 2026 means three subtly different things depending on whether your server is running stock Linux, smeared Google time, or one of the dozens of variants in between. Two timestamps from two providers may disagree by a second, and both are correct under their own definitions.

  That’s what the spec authors call “implementation-defined behavior” and what the rest of us call “why distributed-system logs don’t line up.”

  The number is also a string

  Integers are easy for computers but humans expect a string. Unix time is the easiest timestamp format to compare, sort, and store because it’s an integer, but as soon as we convert to human-readable format, all that changes.

  To find out which one is earlier, subtract. To sort a million events, sort the integers. To store one efficiently, write 8 bytes. To send one over the network, send 8 bytes.

  Compare this to a full ISO 8601 timestamp like 2026-06-04T16:47:23.512847+00:00. That’s a 32-character string that needs to be parsed, validated, normalized for timezone, and converted to a comparable representation before you can do anything with it. Every comparison is a parsing pass. Every storage is 4× the bytes. Every sort is a string sort with calendar rules.

  Unix time is fast. It’s so fast that even formats designed to replace it (Google’s Spanner, AWS’s KSUIDs, Twitter’s Snowflake) embed Unix-like millisecond counts at their core and just append entropy bytes around them.

  The ubiquity isn’t an accident. It’s the natural result of picking the representation that’s cheapest at every step.

  The Untimes

  Unix time is a convention that has eaten the world.

  It’s anchored to UTC, which means it inherits UTC’s quirks. It’s embedded controllers in cars, industrial equipment, network gear, satellite firmware, gas pumps, so pretty much every piece of modern infrastructure.

  1,780,620,532 is just a number, a timestamp. It’s used by your bank for transactions, used by your file system for its files, but also it’s a hack. A 56-year-old dart in the board of of time, that ignores leap seconds, depends on UTC, has three different definitions during the same physical second, and we built the entire internet on top of it.

  Tomorrow will be on what happens when the bill comes due. Y2K and Y2038, the bug that didn’t end the world, and the bug that still might.

  Sources

  • Unix time — Wikipedia
  • Leap second — Wikipedia
  • Coordinated Universal Time — Wikipedia
  • International Earth Rotation and Reference Systems Service — Wikipedia
  • Leap Smear — Google Developers
  • Look Before You Leap — The Coming Leap Second and AWS
  • It’s time to leave the leap second in the past — Engineering at Meta
  • How Precision Time Protocol handles leap seconds — Engineering at Meta
  • Leap second bug cripples Linux servers at airlines, Reddit, LinkedIn — The Register
  • Resolve Leap Second Issues in Red Hat Enterprise Linux
  • History of Unix — Wikipedia
  • Snowflake ID — Wikipedia
  • ksuid — segmentio (GitHub)

  I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

  Jun 5, 2026 Programming Time 30daysoftime Unix

  Enjoyed this?

• Day 12: Earth to Mars, Come In

  NASA’s Mars mission control runs on Mars time, not Earth time.

  For the first few months of every landed mission (Curiosity, Perseverance, Insight), the scientists shift their work schedules by 39 minutes every day.

  They go to sleep 39 minutes later, wake up 39 minutes later, do all their meetings 39 minutes later than yesterday.

  After a few weeks they’re working at 3 AM Earth time. After a month they’re working at noon. After two months they’re back to where they started.

  This is what living on Mars time looks like to humans. It is exhausting and demonstrably bad for sleep. They do it anyway because the rovers don’t care about Earth’s schedule.

  Let’s talk about why time on Mars is hard.

  The sol

  A Martian solar day is called a sol, and it’s about 24 hours, 39 minutes, 35 seconds.

  That’s almost an Earth day. Close enough that NASA’s first instinct in the 1970s was to use Earth time for Mars missions anyway.

  Bad idea. Within a single Martian month, your Earth-time schedule drifts nearly a full day out of phase with the local Martian one.

  The rover’s morning camera shots happen during your meeting. Its solar panels charge while you’re trying to sleep.

  So NASA started using Mars time for the human side of mission ops. They built Mars-time wristwatches in the 1990s, actual mechanical watches modified to run 2.7% slower, and gave them to mission controllers.

  They built Mars-time-aware mission scheduling software. They renamed “day” to “sol” so nobody got confused.

  It worked. It was also brutal on the humans, because human circadian rhythms evolved for Earth’s 24-hour day, not Mars’s 24-hour-39-minute one.

  Mars time shifts your sleep 39 minutes later every day, which is roughly equivalent to flying west across two time zones, every day, forever.

  After a few months I can see everyone getting their schedules wrecked.

  Each rover has its own time zone

  Mars doesn’t have just one time. Each rover gets its own time zone, called Local Mean Solar Time (LMST), based on its specific longitude on Mars.

  Curiosity is in Gale Crater. Perseverance is in Jezero Crater. They are about 3,700 kilometers apart on Mars, and they keep local solar times that differ by about four hours.

  Curiosity is roughly four hours later in its day than Perseverance, because Gale Crater is 60 degrees east of Jezero.

  If you’re a rover and you want to know when the sun will rise tomorrow, you use your LMST, not the other rover’s.

  There’s also a coordinated reference: Coordinated Mars Time (MTC), anchored to Airy Crater, which is roughly the Mars equivalent of Greenwich.

  Airy is where Mars’s prime meridian sits by IAU convention, and MTC is the mean solar time at that location. Most planetary scientists default to MTC when reporting Mars events without specifying a longitude.

  So Mars has its own day (the sol), its own time zones (LMST per location), its own Greenwich (Airy Crater), and its own UTC-analog (MTC).

  The whole planet has built up a parallel set of timekeeping conventions, derived from the same basic problem Earth solved: a rotating body needs a way to talk about when things happen.

  The Moon is being figured out right now

  In 2024, the White House Office of Science and Technology Policy directed NASA to establish Coordinated Lunar Time (LTC) by 2026.

  The Artemis program needs it. So does every commercial lunar lander launching this decade: SpaceX, Blue Origin, ispace, Astrobotic.

  All of them need to coordinate communications, navigation, and surface operations on the Moon, and they need a shared time standard to do it.

  The Moon’s timekeeping problem is harder than Mars’s, for two reasons.

  First, the Moon’s day is 29.5 Earth days long (synodic). A lunar “noon” lasts 14 Earth days, and so does the night.

  The whole concept of “day” as a unit of human activity falls apart. Lunar mission ops will likely use Earth-anchored time for everything and ignore the local sun.

  Second, relativity matters more than you’d think. Clocks on the Moon run about 58 microseconds per day faster than clocks on Earth’s surface, due to the Moon’s weaker gravity well.

  That’s bigger than GPS’s 38 µs/day. If you want a lunar communication network to synchronize with Earth-side networks, you have to bake in the correction the same way GPS did, but more aggressively.

  LTC is being designed right now. The current proposal is an atomic timescale traceable back to TAI, with relativistic corrections applied at the lunar surface.

  It will probably be ready before Artemis 3 lands humans?

  Deep space and the light-delay problem

  Beyond the Moon and Mars, time becomes a different problem entirely: light delay.

  • Round-trip to Mars: 6 to 44 minutes, depending on orbital geometry
  • Round-trip to Jupiter or Saturn: hours
  • Round-trip to Voyager 1, currently 24 billion kilometers from Earth: about 46 hours

  You can’t run NTP to a spacecraft beyond the Moon. The sync protocol assumes round trips of milliseconds, and the universe doesn’t oblige.

  The Deep Space Network (NASA’s array of giant antennas at Goldstone, Madrid, and Canberra) sends time-tagged commands to spacecraft, and spacecraft tag their telemetry with their own onboard atomic clocks.

  The clocks have to be reliable for years or decades without correction, because by the time a round trip resolves, you’ve moved on to the next problem.

  For interplanetary work, physicists use three relativistic coordinate timescales:

  • TCB (Barycentric Coordinate Time): a clock that lives at the center of mass of the solar system. The natural frame for tracking planets, asteroids, comets.
  • TCG (Geocentric Coordinate Time): a clock at Earth’s center. The frame for tracking Earth satellites and orbital mechanics close to Earth.
  • TT (Terrestrial Time): a clock on Earth’s geoid. What UTC is derived from. What humans live in.

  TCG drifts about 22 milliseconds per year from TT. TCB drifts nearly half a second per year from both.

  Most humans never encounter this.

  Anyone doing calculating planetary calculations does.

  The deeper point

  “The day” is parochial. It works only on the body where it’s defined.

  Earth time scales fine on Earth. GPS scales fine in Earth orbit. Mars time scales fine on Mars. None of them scale to each other.

  Every body in the solar system has its own “now,” and there’s no single instant that applies everywhere at once.

  It’s a consequence of relativity. Time literally runs at different rates at different gravitational potentials and different velocities.

  A clock at the solar system barycenter ticks differently than a clock on Earth. There is no “true” rate. There are only frames.

  So how do we coordinate? The standard answer, for spacecraft and astronomers, is to pick a coordinate frame, anchor everything to it, and convert as needed at the destination. TCB for solar-system work. UTC for Earth civilians. GPS for navigation. LTC (coming) for the Moon. MTC for Mars.

  The clocks themselves are “easy” but the coordination between them is the not.

  The civilian question, what time is it if I want to call my friend on Mars, has no clean answer.

  You pick a coordinate frame, you both agree to use it, and you live with the conversion. There’s no “Mars time on your phone” because there’s no Mars infrastructure to sync your phone with.

  And even if there were, you’d still have to handle the light delay.

  Tomorrow we come back to Earth, and to the most ubiquitous time format in human history: the number of seconds since midnight, January 1, 1970.

  Sources

  • Timekeeping on Mars — Wikipedia
  • Coordinated Lunar Time — Wikipedia
  • Barycentric Coordinate Time — Wikipedia
  • Geocentric Coordinate Time — Wikipedia
  • Terrestrial Time — Wikipedia
  • Curiosity rover — Wikipedia
  • Perseverance rover — Wikipedia
  • InSight — Wikipedia
  • NASA Deep Space Network — Wikipedia
  • Voyager 1 — Wikipedia
  • Clockmaker Helps Mars Rover Keep Mars Time — NPR

  I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

  Jun 4, 2026 Space Engineering Time 30daysoftime Mars Nasa

  Enjoyed this?

• Day 9: A Clock You Can Use to Measure a Mountain

  Yesterday I said cesium was about to be deposed. Today’s the deposition.

  The successor is the optical lattice clock. It is so precise that, it can detect the altitude difference between two desks in the same office.

  That last sentence sounds crazy but Its what optical clocks do.

  Here’s how.

  More ticks per second

  The trick of the optical lattice clock is simple in concept: use a finer ruler.

  A cesium atom oscillates at about 9 × 10⁹ Hz (~9 GHz, microwave). That’s how many “ticks” per second the clock has to count to keep time.

  A strontium-87 atom has a clock transition at about 4 × 10¹⁴ Hz (~430 THz, visible light). That’s 50,000 times more ticks per second.

  Same second. More tick marks on the ruler.

  Faster clock makes better time.

  Faster clocks are better than slower ones.

  Faster clocks make for better timekeeping.

  See the difference and why we need to upgrade the second?

  Today’s best optical clocks drift about one second over the age of the universe. 13.8 billion years. Our best cesium clocks are nowhere near that, drifting the same second in roughly 300 million years instead. About a hundred times worse.

  The magic wavelength trick

  So if optical is obviously better, why didn’t we do this first?

  Because it’s hard. Two reasons, really.

  First, you can’t just point an optical clock at a free-floating atom. Atoms in flight have all sorts of velocity, Doppler-shifting the frequency you measure. You have to hold them still. But the only way to hold an atom still is to grip it with something, and gripping it with a laser changes the energy levels you’re trying to measure. Catch-22.

  Second, even if you could pin the atom, you couldn’t count that fast. Microwave at 9 GHz fits inside what electronics can divide down and tick off. Visible light at 400+ THz does not. We had no way to count optical-frequency oscillations until the optical frequency comb showed up in 1999, work that won Hänsch and Hall the 2005 Nobel.

  In 1967 when the CGPM picked cesium, none of this existed. The laser was seven years old. Laser cooling wouldn’t be demonstrated until the late 1970s. Frequency combs were 30+ years away. Cesium at 9 GHz wasn’t the best clock you could imagine. It was the best clock you could build.

  The fix came in 2003 from a Japanese physicist named Hidetoshi Katori. He proposed trapping the atoms in a standing-wave laser pattern, a 3D optical lattice, like an egg crate made of light, and tuning the lattice laser to a specific frequency called the magic wavelength.

  At the magic wavelength, the lattice light affects both energy levels of the clock transition by exactly the same amount. The trap is invisible to the clock. The atoms are held still, but the energy levels they emit at are unperturbed. You get to measure the atomic transition cleanly while the atom sits frozen in midair.

  Optical lattice clocks are a beautiful piece of physics. Do not ask me about the math behind them.

  Which atom?

  Two main candidates have been thinking about for the title of “next SI second”:

  • Strontium-87. Run in optical lattices by labs around the world: NIST/JILA in Boulder, NPL in the UK, RIKEN in Japan, SYRTE in Paris. About 1 part in 10¹⁸ uncertainty. Currently the favorite.
  • Ytterbium-171. Comparable accuracy, different sensitivity profile (different ways the clock can go wrong, which is good for cross-checking against strontium).

  There are also trapped-ion optical clocks, which hold a single ion in an electric field instead of a lattice of neutral atoms. The aluminum-ion logic clock at NIST has hit about 1 part in 10¹⁹. That’s one second of drift in 300 billion years. The amount of drift is older than the universe itself. That sounds pretty good to me.

  What this gets you

  Optical clocks are sensitive enough to see general relativity at human scale.

  What does that mean? It means you can put two clocks on different shelves and watch one tick slower than the other.

  Einstein said clocks deeper in a gravitational field run slower than clocks higher up. Near Earth, the effect is about 1 part in 10¹⁶ per meter of altitude. A clock on the floor runs slower than a clock on the table. For most of human history this was a theoretical curiosity. Now it’s a measurement.

  In 2022, a JILA strontium clock measured a 1 millimeter height difference as a frequency shift. One millimeter. The thickness of a credit card. The clock could tell which side of the card it was sitting on, from gravitational time dilation alone.

  This opened a new field: relativistic geodesy. Put an optical clock at two locations, compare frequencies, and you’ve directly measured the gravitational potential difference between them. Detect underground oil, magma movement, ice sheet melt, anything that shifts mass around the planet.

  Cesium can’t do this.

  The next “second”

  The BIPM is planning to redefine the SI second around an optical transition by 2030. Same dance as 1955: measure the new number against the current cesium standard, freeze it at that precision, declare it the new second.

  Four layers of backwards-compatibility instead of three. The fingerprints accumulate.

  Where this goes

  We’ve now spent three days on how a second is built. The next question is the one the calendar dodges: which second?

  You need a reference point. A zero. An origin.

  Tomorrow we’ll talk about where you start counting from, and why astronomers picked noon on January 1, 2000.

  Sources

  • Optical clock — Wikipedia
  • Hidetoshi Katori — Wikipedia
  • Quantum logic clock — Wikipedia
  • Relativistic geodesy — Wikipedia
  • Bothwell et al., Nature 2022 — millimeter-scale gravitational redshift
  • Gravitational time dilation — Wikipedia
  • Jun Ye — Wikipedia
  • Epoch (astronomy) — Wikipedia

  I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

  Jun 1, 2026 Science Time Physics 30daysoftime Metrology

  Enjoyed this?

• Day 8: 9,192,631,770

  Today’s number is 9,192,631,770.

  That’s how many times a cesium-133 atom oscillates between two specific energy states in one second. Or, more precisely, it’s how many times we decided a cesium atom does that in one second. The number is doing some heavy lifting that the universe didn’t ask for.

  This post is about the number, how it got picked, and how we use it to measure time.

  The chain

  To know what a second is, you need a way to measure one. For most of human history, the answer was: “look at Earth and count” or earth++ for the programmers reading this.

  One second = 1/86,400 of a mean solar day.

  That worked for sundials and pendulum clocks. It stopped working in the 1930s, when good quartz clocks revealed that Earth’s rotation isn’t uniform. Yesterday, we talked about how. Earth’s rotation is not a good measurement of time. I mean good in the sense of precise, because there are so many variables that go into the rotation and impact it. We don’t have an accurate way to measure and predict how those variables change.

  In 1960, astronomers tried again. Because why not? Wheel, reinvented.

  They picked Earth’s orbit instead of its rotation, which is far more stable:

  One second = 1/31,556,925.9747 of the tropical year for 1900.

  That weird denominator was chosen specifically so the new “ephemeris second” came out the same length as the old mean solar second. Don’t break clocks … like ever.

  Great in principle, terrible in practice. To know what time it was, you had to consult a 60-year-old astronomical table. It doesn’t work with the clock in the lab. The ephemeris second won the philosophy and lost the engineering.

  But wait, maybe there’s a third option.

  How I wish it was Cesium-123 and not Cesium-133, but alas. The 133 is the mass number: 55 protons + 78 neutrons. Cesium-133 also happens to be the only stable isotope of cesium, so it kind of picked itself.

  The cesium handoff

  Cesium-133 has two slightly different ground-state energies. Drop an atom from one to the other and it spits out a photon at a specific frequency, call it f. If you can build a clock that locks itself to that frequency, you have a timekeeper that doesn’t depend on the Earth, the Sun, or any astronomer’s table. Every cesium-133 atom in the universe agrees on f to absurd precision, because quantum mechanics doesn’t have local variants.

  The number for f is approximately 9.192631770 GHz. So if you count 9,192,631,770 oscillations, exactly one second has elapsed.

  In 1967, the General Conference on Weights and Measures (the CGPM, the body that gets to define units) voted to make that the official definition. The SI second became:

  The duration of 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the cesium-133 atom.

  No Earth, no Sun, no tables. Just an atom.

  Why that exact number

  The number 9,192,631,770 is not a fundamental constant of the universe. It was measured. By two specific guys. In 1955.

  Their names were Louis Essen and Jack Parry, and they worked at the National Physical Laboratory in the UK. They had just built the first cesium clock that actually worked. The question was: how many cesium ticks fit in one ephemeris second? They measured it carefully. Their answer, published in 1958 with William Markowitz and Robert Hall:

  1 ephemeris second = 9,192,631,770 ± 20 cesium periods.

  Nine years later, the CGPM took that number, dropped the uncertainty, and made it the definition. From then on, the second was defined as exactly 9,192,631,770 ticks. The plus-or-minus twenty disappeared.

  This means three things:

  1. The cesium second was chosen so it would equal the ephemeris second.
  2. The ephemeris second was chosen so it would equal the mean solar second.
  3. The mean solar second was 1/86,400 of an Earth day.

  The three layers of don’t break the previous standard. If Essen and Parry had been off by one in their measurement, the entire SI second would be slightly different today, and every clock and computer and GPS satellite would be calibrated to that other version.

  The number is a historical fingerprint, not a physical constant.

  It records, with eleven decimal-digit precision, exactly how well two physicists in 1955 could compare a cesium clock to an Earth-orbit calculation.

  Every GPS satellite, every NTP server, every timestamp on every photo you’ve ever taken, they’re all calibrated to the limits of what Essen and Parry pulled off with 1955 equipment. The universe doesn’t care about your iPhone. Your iPhone cares about two guys at the NPL.

  How precise are we now

  Modern cesium fountains, the latest generation, where atoms are laser-cooled and tossed gently upward through a microwave cavity, falling back down under gravity like a slow ballistic juggling act, hit accuracies of about one part in 10¹⁶. That’s roughly one second of drift per 300 million years.

  NIST-F2 in Boulder, the U.S. primary clock, is one of these. About a dozen others sit in metrology labs across France, Germany, the UK, Japan, and China. They all report their measurements to the BIPM in Paris, which combines them into a weighted average called TAI, International Atomic Time. TAI is what your phone’s clock is ultimately disciplined to, through a long chain of NTP servers and GPS signals.

  Everything you do that involves time:

  • sending a message,
  • taking a photo with a timestamp,
  • syncing with a calendar,
  • getting a stock trade priced

  It all traces back to a few hundred atomic clocks averaging each other in real time.

  What comes next

  Cesium won’t be the way we measure the second forever. It’s about to be deposed.

  Optical lattice clocks, using strontium or ytterbium atoms instead of cesium, operating at visible-light frequencies instead of microwave, are now about a hundred times more precise. They lose one second per about 30 billion years, which is roughly twice the age of the universe.

  The BIPM is planning to redefine the SI second around an optical transition, possibly by 2030.

  When that happens:

  1. Mean solar second = 1/86,400 of an Earth day
  2. Ephemeris second chosen to match the mean solar second
  3. Cesium second chosen to match the ephemeris second
  4. Optical second chosen to match the cesium second ← the new one

  Three layers of backwards-compatibility will become four.

  Tomorrow we’ll look at those optical clocks, what they are, how they work, and how they let us measure what cesium can’t.

  Sources

  • Louis Essen — Wikipedia
  • William Markowitz — Wikipedia
  • Second — Wikipedia
  • Ephemeris time — Wikipedia
  • Atomic clock — Wikipedia
  • International Atomic Time — Wikipedia
  • NIST-F2 — Wikipedia
  • Optical clock — Wikipedia

  I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

  May 31, 2026 Science Time Physics 30daysoftime Metrology

  Enjoyed this?

• Day 7: A Day Is Not 24 Hours

  Last week we talked about what time is, what it might not be, and what your brain does to make you feel it. This week we measure.

  The obvious place to start is to look up at the sky. Humans did this for several thousand years before they realized how badly the sky was lying to them.

  The Sundial Problem

  The oldest clock is a literal stick in the figurative ground.

  Watch the shadow move. When the shadow is shortest, the sun is overhead. That’s noon.

  For a long time, this was good enough. If you wanted to coordinate a meeting in ancient Egypt, you and your buddy could both look at the sun and agree on roughly when to show up. Our Civilizations were built on this.

  Here’s the problem. If you mark where noon falls on a sundial every day for a year, and compare it to a clock that ticks steady seconds, the sundial drifts. Sometimes the sun is “late.” Sometimes it’s “early.” Over the course of a year, the gap swings by up to about sixteen and a half minutes one way (early November) and just over fourteen minutes the other (mid-February).

  This is called the equation of time, and it has two main causes.

  First, Earth’s orbit isn’t a circle. It’s an ellipse. We move faster when we’re closer to the sun (around January 3rd) and slower when we’re farther away (around July 4th). When we’re moving faster, the sun appears to drift across the sky faster, and noon comes sooner than the clock predicts.

  Second, Earth’s axis is tilted. The sun doesn’t ride along the equator, it rides along the ecliptic at a 23.5 degree angle. That tilt distorts the projection of the sun’s motion onto our daily rotation, which means the sun runs ahead of the average for parts of the year and behind it for others.

  If you graph the equation of time across a year, you get a wobbly figure-eight called the analemma. You’ve probably seen it on a globe somewhere and ignored it. It’s the actual shape of “noon” over a calendar year.

  So if you want a 24-hour clock that doesn’t drift around with the seasons, you can’t use a sundial directly. You have to average. The result is called mean solar time, the time you’d see if the sun behaved itself.

  Two Kinds of Day

  Hopefully following along so far, because now we need to talk about what a “day” is. There are two ways to define it and they disagree.

  The solar day is what you’d guess. Sun is straight overhead; rotate Earth until the sun is straight overhead again. That’s one day. About 24 hours.

  The sidereal day is what astronomers use. Pick any distant star; rotate Earth until that star is back in the same position in the sky. That’s one sidereal day.

  A sidereal day is 23 hours, 56 minutes, and 4.09 seconds. Almost exactly four minutes shorter than a solar day.

  Why? Because Earth is doing two things at once.

  While you spin on your axis, you’re also moving around the sun. By the time you finish one full rotation relative to the stars, you’ve also moved a tiny bit along your orbit. The sun has effectively shifted in the sky from your perspective. You have to rotate a tiny bit further to point at the sun again.

  That tiny bit further takes about four extra minutes. Add it up over 365 days and it equals exactly one full rotation. That’s why a year has one more sidereal day than solar days. The arithmetic comes out clean. The universe is just doing this weird double-counting thing where one of your rotations gets eaten by your orbit.

  If you’re an astronomer trying to point a telescope at a star, sidereal time is what you want. The star is in a fixed place in inertial space; your dome needs to compensate for Earth’s actual rotation, not for “where the sun appears to be.”

  If you’re a person trying to know when to eat lunch, solar time is what you want. The sun is the thing your body cares about.

  These two definitions don’t reconcile. They are answering different questions.

  Earth Doesn’t Tick Steadily

  Even after you average the equation of time and pick which kind of day you want, Earth still doesn’t make a great clock.

  Earth’s rotation is slowing down. Tidal friction with the Moon transfers angular momentum outward, the Moon drifts farther away (about 3.8 centimeters per year, measured by bouncing lasers off Apollo-era retroreflectors), and our days get longer by roughly 1.7 to 2.3 milliseconds per century. Slow, but cumulative. A really, really long time ago, a day was about 22 hours.

  So we know, Earth’s rotation is jittery in the short term. The atmosphere (air mass) sloshes around with weather. Ocean currents shift mass around because hot water weighs less than cold water. There is some coupling between the outer core and the mantle that yanks the rotation rate around. It’s very hard to predict all these factors in advance. All of these factors cause the the length of a day to fluctuate from one week to the next.

  For a long time none of this mattered. If a day was off by a few milliseconds, who cares? Sundials don’t have that resolution.

  The moment it started mattering was when we got better clocks than the those based on the Earths rotation.

  How We Measure Earth’s Rotation Today

  I hope you are ready to learn some astronomy.

  The most precise measurement of Earth’s rotation right now comes from watching distant quasars, supermassive black holes billions of light years away whose positions in the sky are effectively fixed. A technique called Very Long Baseline Interferometry, or VLBI, uses arrays of radio telescopes spread across continents to triangulate Earth’s exact orientation against these quasars.

  That’s worth reading again. The way we figure out what time it is on Earth is by triangulating against the cores of ancient galaxies billions of light years away.

  VLBI pins down Earth’s orientation to the level of microseconds and millimeters. It’s how we know, day by day, by exactly how many milliseconds the planet ran fast or slow. It’s how we know, to staggering precision, exactly how badly the planet underneath us is failing to be a steady clock.

  That measurement, and what we did about it, is going to matter in a bit, in future articles. This week on Time is all about how we measure time.

  Tomorrow: the second we use today isn’t measured by Earth at all. It’s measured by an atom that doesn’t care which planet you’re on.

  Sources

  • Equation of time — Wikipedia
  • Sidereal time — Wikipedia
  • Earth’s rotation — Wikipedia
  • Seeing the Light: lunar laser ranging — Eos
  • VLBI — NASA Earthdata

  I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

  May 30, 2026 Science Time 30daysoftime Astronomy

  Enjoyed this?

• Day 6: Your Brain Is Lying to You About Time

  Yesterday I told you a fly’s now is much shorter than yours and a whale’s is much longer. Today I want to talk about how wide your now actually is, and why none of it is what your brain is showing you.

  The short answer is that your brain is editing.

  The Saddleback

  In 1882, a philosopher writing under the pseudonym E. R. Clay noticed something obvious that nobody had said cleanly before. The “present” of physics, a knife-edge with zero duration separating past from future, is not the present you actually experience.

  When you hear a melody, you are not perceiving one note at a time and then assembling them from memory. You are hearing the melody. The first three notes are still vividly present even as the fourth arrives. They haven’t dropped into recall yet. They’re still in the room.

  Clay called this experienced now the specious present. Specious because it isn’t really the present, it’s a stretched window that the brain treats as a single perceptual moment.

  William James picked the idea up in 1890 and gave it the metaphor people still use:

  “The practically cognized present is no knife-edge, but a saddle-back, with a certain breadth of its own on which we sit astride, and from which we look in two directions into time.”

  You don’t sit on a point. You sit on a saddle. From the saddle, you can see a little way into the just-past and a little way into the just-coming. All of it feels like now.

  How wide is the saddle? Modern cognitive science puts the boundary at roughly 2 to 3 seconds. Beyond that, things start to feel like memory rather than experience.

  The 3-Second Rule Shows Up Everywhere

  A German chronobiologist named Ernst Pöppel spent decades chasing this number across human behavior, and what he found is uncanny.

  Spoken phrases across all studied languages cluster around 3 seconds. Lines in poetry, going back to ancient Greek hexameter, sit in that range. When you stare at an ambiguous image like the Necker cube, your brain flips its interpretation every 2 to 3 seconds, automatically. Even people clapping along to music will, without prompting, fall into clusters of beats roughly 3 seconds wide.

  This isn’t because the universe has a 3-second resonance. It’s because that’s the size of cognitive chunk your brain processes as a coherent now. Everything you build out of moments, language, music, attention, conscious experience, is laid down in saddles roughly that wide.

  3 syllable words are more likely to be used, and thus carry more meaning than 13 syllable words.

  The Lie About Order

  It gets worse. Inside the saddle, your brain is actively rewriting the order of events.

  Light and sound travel at different speeds. The signals from your eyes and ears take different times to reach your cortex. If your brain just delivered each signal to consciousness whenever it arrived, the world would feel much different, with everything out of sync.

  So instead, your brain buffers. Within about an 80-millisecond window, it pulls events back into alignment. What you experience as “now” is the output of that stitching, not the raw signal.

  Another way to think about this is that if a flash and a bang happen within 80 ms of each other, the brain rewrites the timing and presents them as simultaneous, regardless of which one your neurons actually processed the “event” first.

  You don’t experience the truth. You experience the post-production cut.

  The clean stream of reality, where dialogue lines up with mouth movements and you can catch a ball without thinking about it, is a fiction the brain is generating in real time.

  When the Editor Breaks

  The cleanest evidence that the present is a construction is what happens when the constructor breaks.

  There’s a rare condition called akinetopsia, motion blindness. People with akinetopsia, usually after damage to a brain region called V5, lose the ability to perceive continuous motion. They see the world as a series of static snapshots. A car is here, and then it’s there, and they never see it travel between. Water pouring from a pitcher looks frozen, like ice. A dog mid-leap is a still photograph.

  These people are not blind. Their eyes work. What’s broken is the part of the brain that stitches the saddleback together. Strip that out, and you don’t see “time” anymore. You see disconnected frames.

  The flow of time is something your brain is doing. Not something it’s perceiving.

  Why a Year Feels Shorter Every Year

  Now for the part that’s going to depress you.

  In 1877 a French philosopher named Paul Janet pointed out something nobody likes admitting. The reason a year felt long when you were five and feels short when you’re forty is mathematical. At five, a year is one-fifth of your entire existence. At forty, it’s one-fortieth. The same calendar interval is a much smaller fraction of who you are.

  This is intuitive but it isn’t the whole picture. The deeper explanation, from the psychologist Robert Ornstein in 1969, is about memory density. The brain reconstructs how long a past period felt by counting how many distinct memories it can pull from it. Childhood is packed with first times: first day of school, first bike ride, first betrayal. Memory traces are dense. In hindsight, the period feels enormous.

  Adulthood is the opposite. You drive the same route to the same job and eat the same lunch. The brain, energy-thrifty as ever, throws most of that away. When you look back at the last year, there isn’t much to find. The conclusion your brain delivers: that year barely happened.

  If you’ve ever come back from a two-week vacation in a new country and felt like you’d been away for a month, you’ve seen the other side of this. Novelty stretches the look-back. Routine erases it.

  The way to slow down the rest of your life is to keep making first memories.

  The Slow-Motion Crash Is a Lie Too

  People who survive car crashes routinely report that time slowed down. The world stretched. Their hands moved through molasses. The popular explanation is that adrenaline ramps up neural processing, your brain “speeds up” in danger, and so the world appears to slow down.

  It’s a great story, and it’s wrong.

  The neuroscientist David Eagleman tested this directly in the early 2000s by getting volunteers to free-fall from a 31-meter tower into a net. While they fell, they wore a wristwatch that flashed numbers faster than the human eye can normally read. Eagleman’s bet: if perception really speeds up in fear, the falling subjects should be able to read the watch.

  They couldn’t. Their perception didn’t speed up at all.

  But afterwards, asked to estimate how long the fall lasted, they all overestimated dramatically. The fall felt long in retrospect.

  The slow-motion is a memory effect. In a crisis, your brain switches into high-density recording mode. It lays down vastly more memory traces per second than usual. When you reconstruct the experience afterward, all those dense memories make it feel like the event took forever. You weren’t seeing slowly. You were remembering richly.

  The present moment was the same as always. The look-back is the lie.

  Where We Go From Here

  We’ve spent a week on what time is, what it might not be, and how your brain assembles the experience of it.

  Tomorrow we leave all of that behind. For the next two weeks, time stops being a thing you feel and becomes a thing you measure. The hard sciences are coming. We’ll start with how human beings figured out how long a day actually is, and why the answer changed depending on the century.

  Sources

  • Specious present - Wikipedia (E. R. Clay and William James)
  • Temporal Consciousness - Stanford Encyclopedia of Philosophy
  • Ernst Pöppel - Wikipedia (3-second window research)
  • Akinetopsia - Wikipedia (motion blindness and V5)
  • David Eagleman - Wikipedia
  • Stetson, C., Fiesta, M. P., & Eagleman, D. M. “Does Time Really Slow Down during a Frightening Event?” PLOS ONE 2(12): e1295 (2007)

  I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

  May 29, 2026 Neuroscience Time 30daysoftime Perception Psychology

  Enjoyed this?