--- title: "The Schedule Bug That Pointed Back to March 4, 1973" canonical: https://dxdev.com/everyday-ai/1973-date-that-wasn-t-in-the/ datePublished: 2026-04-10 --- The schedule on the screen was full of recent events, and one old date kept showing up in the trail behind a list that had started putting events in the wrong order: March 4, 1973. No event in the system had come anywhere near that day. So why was it the clue? Ordinary testing did not catch it. Normal test dates and a casual look at the list gave no reason to suspect trouble. The failure needed a very particular pairing: dates on opposite sides of a digit-width change, plus a location tie-break. Ordinary tests never produced that pairing, so the flaw stayed hidden for years. ## What the schedule was doing The schedule had one simple job. It gathered a set of entries, gave each one a number based on its date and time, and put the smallest number first. Think of numbered recipe cards on a kitchen table. Card 3 comes before card 12. A date stored as a number works the same way. Earlier dates have smaller numbers, so they rise to the top. Then there was a small exception. If two entries needed a second way to break a tie, the system added the location name to the end of the date number. That made the tie predictable. It also changed what the date was. A number with a word stuck onto its end is no longer a number. It is text. That sounds harmless, and for a long time it was harmless enough to escape notice. But the list now held two kinds of cards. Some carried a plain date number. Others carried a date number followed by a location. When the system compared two plain numbers, it put them in time order. When even one side was text, it used a different rule. ## The rule nobody meant to use The scary name for that rule is **lexicographic order**. It just means reading from the left, one character at a time, like sorting words in a dictionary. It does not ask which number is bigger. It asks which character appears first. Here is why that matters. A 12-digit date number that begins with `1` can be much later than an 11-digit date number that begins with `9`. As numbers, the 12-digit value is much bigger. As text, the first character decides it. Since `1` comes before `9`, the later date can get pushed ahead of the earlier one. That is where March 4, 1973 came from. The date system counted time in milliseconds, tiny slices of a second, starting from January 1, 1970. On March 4, 1973, the count crossed from 11 digits to 12. Nothing special happened to any event that day. It was simply one of the places where the number gained another digit. Once dates of different widths were being compared as text, that extra digit mattered in a way it never should have. So the schedule had to include dates on different sides of a digit-width change, and some entries also had to take the location tie-break path that turned their date number into text. If either condition was missing, the list looked fine. Ordinary dates hid the mismatch. ## The fix The fix was small, but the idea behind it was careful. Before anything could add a location name, the date number was given a fixed width of 15 characters. Shorter numbers got zeroes placed in front of them. Now every date card had the same number of spaces, whether it was old or new. A leading `1` and a leading `9` sit in the same position for every event, so text order and date order finally agree. There was already an older workaround nearby for dates before 1970, when the time count turns negative. That was a useful reminder. Dates feel ordinary because we use them every day, but the computer version has edges. It has a zero point. It can become negative. Its number can grow another digit. And a tiny shortcut, like adding a word to a number, can change the rules without anyone noticing. If your systems sort by a date combined with other text, ask your team whether the date is padded to a fixed width, and make sure tests include dates on both sides of a digit-width change.