The Calendar Test
The calendar test is one question, asked of any risk analogy or any argument about when a program should start: can you circle the failure date on a calendar? A yes and a no lead to completely different plans, and most disagreements about post-quantum urgency are really disagreements about which answer applies. The test takes a sentence to run and it settles the argument in front of you, because the two answers describe two different shapes of risk that happen to be discussed in the same meeting.
The short version:
- Ask one question of the risk or the analogy: can you circle the failure date on a calendar?
- Yes means you plan backward from the date. Scope, schedule, verify, finish before it arrives. Y2K worked this way.
- No means the event is a threshold somebody crosses in private, so there is nothing to count down to and you plan on lead time instead.
- Then ask the follow-up that sets urgency: does the damage wait for the threshold, or does it start at capture?
- The application rule for any analogy: keep the work half, audit the clock half. Inventory, prioritize, replace and verify transfer almost perfectly between programs. The clock rarely does.
A fire drill and a flood plain are both risks, and only one has a date. The drill is scheduled, so you prepare for Thursday. The flood is a threshold in a river you do not control, so you build the house higher and you buy the insurance before the season, because there is no Thursday to prepare for. Arguing about which one the quantum transition resembles is the whole board conversation, and the calendar test answers it in one move.
What is the test, exactly?
Two questions, asked in order, of the risk itself rather than of any particular system.
| Question 1: the calendar | Question 2: the damage | |
|---|---|---|
| What it asks | Can you circle the failure date? | Does harm wait for the threshold, or start at capture? |
| A yes means | Plan backward from a fixed date | Harm begins later, so the deadline is the deadline |
| A no means | Plan on lead time, because no date exists to plan against | Harm has already begun, and the deadline is behind you |
| What sets it | Whether the event is public and scheduled, or private and crossed | Whether the attack needs you present, or works on stored material |
Question 1 sorts the risk. Question 2 prices the delay. A risk can fail question 1 and still be relaxed, if nothing accumulates while you wait. A risk that fails both is the expensive kind, because the waiting itself is where the loss happens.
The test interrogates the clock structure of a risk or an analogy. It does not date a particular system, which is a different job done by The Two-Clock Test. Run the calendar test to settle what kind of risk you are looking at, then run the two-clock test on each system to get its two actual dates.
How does Y2K score?
Y2K passes question 1 cleanly. The failure date was 1 January 2000, everyone could see it, nobody could move it, and the entire program was planned backward from it. On question 2, the harm waited. A system with an unremediated date field was fine until midnight, so finishing the day before was genuinely finishing.
That combination is why backward planning worked, and the record shows how much work it took. The US Senate Special Committee on the Year 2000 Technology Problem put the American bill at an estimated 8.5 billion of that inside the federal government, and the Office of Management and Budget put federal spending specifically at $8.34 billion. The Committee also wrote down its verdict on whether that was worth it: “In the Committee’s judgment, the level of effort was justified, and the expenditures of the public and private sectors were indeed necessary.”
The same report contains the detail that makes it useful in an argument. Testing during the last quarter of 1999 predicted an embedded chip failure rate of .001%, against the 2-3% rate projected in late 1998 and early 1999. That improvement is the output of the remediation, which means citing the small final number as proof the threat was oversold reverses the causality.
How does Q-Day score?
Q-Day fails question 1. No date is published, because the event is a private threshold rather than a scheduled announcement: the moment somebody first operates a machine capable of breaking deployed public-key cryptography. The party that reaches it first has every reason to stay quiet, since the value of that capability sits in the reading rather than in the telling, and saying so out loud would prompt every target to migrate.
It fails question 2 as well, and this is the part that changes the budget. Under harvest now, decrypt later, ciphertext copied today is decrypted whenever the capability arrives, so the loss attaches at the moment of capture rather than at the moment of the break. Data with a long required secrecy lifetime is therefore already exposed, and waiting adds to the pile rather than holding it steady.
Failing both questions is what separates this from the analogy it gets compared to. Y2K gave you a date and let you finish. This gives you neither.
What replaces a countdown when there is no date?
A band, with its assumptions written down. The published expert surveys collected in Quantum Threat Timeline give a probability spread rather than a year, and a spread is the correct instrument for a threshold nobody will announce. Plan against the pessimistic end of it, because planning against the middle means the program is late in exactly the scenarios it exists for.
Then convert the band into something a plan can use, which is lead time rather than a due date. Mosca’s Theorem does that arithmetic: secrecy lifetime plus migration time, measured against the arrival window. Any asset where the first two exceed the third is late already, and no resolution of the arrival date is needed to know it.
Common misconceptions
A quiet outcome proves the threat was fake. This is the Y2K argument in its most common form, and the Senate answered it before it was made. The Committee judged the effort justified and the expenditures necessary, and the failure-rate collapse from 2-3% to .001% is the remediation working rather than evidence it was unnecessary.
The countdown will start when the capability is real. A countdown requires an announcement, and the owner of a first capability has every incentive to withhold one. Any plan that begins when the news breaks begins after the collection it was meant to prevent.
An analogy is either right or wrong. Analogies split. Y2K’s work half transfers almost perfectly, because finding a boring buried defect across an entire estate and fixing it against a clock is exactly the shape of this program. Its clock half does not transfer at all. Taking the whole thing or rejecting the whole thing both lose the useful part.
No calendar means no urgency. Question 2 exists for this. The absence of a date removes the deadline, not the accumulation, and for harvestable long-lived data the accumulation is the entire loss.
Pro tips
Carry the two-sentence rebuttal. When Y2K arrives as a dismissal, the answer is that the work half transfers and the clock half does not, and that the quiet outcome was purchased rather than lucky. Two sentences, and they turn the analogy from an objection into a precedent for funding.
Attach the receipt. The Senate report is a public government document with a citable number, S. Prt. 106-42, February 2000. A board that has just heard Y2K used as a punchline reads the Committee’s own verdict differently than it reads yours.
Use the estimate honestly. The report itself says the worldwide cost of preparing for Y2K may never be known, and it cites a wide spread of outside estimates. Say “an estimated $100 billion” and attribute it, rather than treating any of the circulating figures as audited.
Run the test out loud in the meeting. The question is short enough to ask in front of everyone, and asking it publicly converts a disagreement about urgency into a shared observation about the risk’s structure.
Where does the test break down?
It stops being interesting when the answer to question 1 is simply yes, and several parts of this transition do have real calendars. Regulatory deadlines are dates on a calendar in exactly the ordinary sense: the EU Cyber Resilience Act obligations, the migration phases in the federal execution memo, and the deprecation and disallowance years proposed in NIST IR 8547. For those, the test returns yes and hands you straight back to backward planning, plus The Two-Clock Test to check the compliance date against the exposure math.
It also has nothing to say about which systems matter most. Sorting the estate is a different instrument, handled by The Two-Lane Split and The Shelf-Life Question. The calendar test tells you what kind of clock you are on, and stops there.
How do you use it in a boardroom?
The wield-upward form is the question itself, asked of whatever analogy is on the table: “Can we circle the failure date on a calendar?”
When the answer is no, the follow-up does the work, because the board has just been told there is no deadline and needs to hear why that makes the item more urgent rather than less. Ask whether the damage waits or starts at capture. For anything with a long confidentiality requirement it starts at capture, which means the item on the agenda is an accumulating loss with no due date at all, and the only variable the board controls is how much more accumulates before the program starts.
That reframing is what makes the funding conversation possible. A deadline-shaped item competes against every other deadline and loses to the nearest one. An accumulating item competes on how long it has already been running.
Questions people ask
Is Q-Day just Y2K all over again? Half of it is, and the half that transfers is the useful half. Both are boring buried defects spread across an entire estate that have to be found, prioritized, replaced and verified. The clocks are opposites: Y2K had a public fixed date and its harm waited for midnight, while this has no date and its harm starts at capture. Is Q-Day Another Y2K works the comparison in full.
Doesn’t the absence of a date mean I can wait? It means the opposite for harvestable data. A deadline gives you permission to start late and still finish on time. A threshold with retroactive damage gives you no such permission, because every month of waiting adds ciphertext to somebody’s archive that a later capability reads.
How is this different from the two-clock test? Scope. The calendar test asks what kind of clock a risk or an analogy runs on. The Two-Clock Test takes one specific system and states its two dates, the mandate date and the exposure date. Run this one first to settle the argument, then that one per system to get the numbers.
What if my leadership insists on a single date for the plan? Give them the band and the lead-time math instead, and say plainly which is which. A range with inspectable assumptions survives scrutiny. A single invented year gets treated as a real commitment and then discredits the whole program when it passes uneventfully.
Does this apply to authentication as well as encryption? Question 1 does, identically. Question 2 changes, because forging a signature requires the machine at the moment of the attack, so authentication carries no harvest exposure and its damage does wait for the threshold. Long-lived signed artifacts pull lifetime back into the picture on the trust side, which Forge-Later Attack covers.
Which other risks does the test run on? Any risk offered with a historical analogy attached. It works on the SHA-1 deprecation, which had real dates and behaved accordingly, and on regulatory deadlines, which return a clean yes. A test that only worked on the case it was invented for would not be worth naming.
Who actually decides the answer to question 2? The data does. Ask how long each dataset must stay confidential, and whether its protection rides on key exchange that a future quantum computer breaks. The Shelf-Life Question is that question in its portable form, and it needs no cryptographic background to answer.
Everything here is the map, given freely. When the test has to be run across a real estate, with the bands sourced, the lead-time math done per system and the result written into a register that survives an auditor, that is the work I do. Request the workshop.
Last verified 2026-09-03 · Maintained by Addie LaMarr, LaMarr Labs.