Punctuality: Hard Real-Time vs Best-Effort

"9 AM" is not a time. It is a protocol setting, and nobody told you which one this office runs.

Your calendar says the meeting is at 9. What nobody documents is what 9 means here. On one grid it means 8:55, seated, coffee already handled. On another it means somewhere in the 9:15 range, after the greetings, which are not optional. Guess wrong in either direction and the grid quietly files a defect report against your character.

This is the Foreign Engineer’s Field Guide, translation lane. This entry is about clocks, and why yours is not wrong, just running a different scheduler.

Two Schedulers

Two scheduler families, two contracts. In a hard real-time system, a missed deadline is a system failure, full stop. The airbag that fires 40 milliseconds late did not fire. A best-effort system offers no deadline contract at all. It promises to try, and it optimizes for throughput and fairness, not for any single clock edge. The deadline is your problem.

Cultures implement both. Hard real-time grids treat 9:00 as a contract: arrival at 9:04 is the airbag firing late, and the content of your excuse is irrelevant because the failure already happened. Best-effort grids treat 9:00 as a rendezvous hint: the meeting starts when the people are assembled and warmed up, because the assembly and the warmth are part of the meeting, not overhead before it.

Neither is broken. Hard real-time buys predictability and low coordination cost. Best-effort buys flexibility and relationship bandwidth. But they do not interoperate, and you are the process migrating between two schedulers, carrying your old expectations as state.

Reading the Wrong Clock

Both directions fail, and both failures stick to you, not to the clock.

Arrive ten minutes late on a hard real-time grid and you have not inconvenienced anyone. You have emitted data. The grid logs one sample of “unreliable” and the log is append-only. Three samples and you are the person who is always late, a reputation that will outlive years of shipped work, because on that grid punctuality is not logistics. It is a proxy for whether your promises mean anything.

Now invert it. On a best-effort grid, your rigid punctuality reads as a defect too. You arrive at the stated time and sit alone in a room, visibly annoyed, radiating judgment. You open with agenda item one while the room is still exchanging the greetings that establish trust, and the grid files you under cold, impatient, possibly hostile. The relationship block you skipped was not overhead. On that grid, it was the first agenda item.

And then there is “let’s have lunch sometime.” Same string, linked against different libraries. On one grid it resolves to a real function: someone now expects a date on the calendar. On another it resolves to a no-op, a politeness token that executes nothing. Call the no-op eagerly and you look pushy. Ignore the real function and you look aloof.

Deadlines Have Types Too

The same mismatch runs through project time. “End of quarter” is a hard deadline on one grid and an aspiration with error bars on another, and the word “deadline” will not tell you which. Teams blow up over this constantly: one side thinks it committed to a target, the other side thinks it received a promise.

You cannot read the type from the word, but you can query it. One question, phrased as planning, not doubt: “so I schedule this right, what happens if it slips a day?” The answer tells you the service class immediately. “The customer demo dies” is hard real-time. “We would rather it did not” is best-effort. Ask it every time.

Sync Your Clock, Do Not Replace It

The fix is the same one this whole arc keeps prescribing: do not rewrite your internals, adapt at the boundary. Your machine does not argue with the network clock or replace its own crystal. It syncs, applies an offset, and moves on.

Build the offset table for your local grid. Not one global rule, an entry per event class, because grids are not uniform even internally. Interviews and customer calls are hard real-time almost everywhere on earth. Internal meetings vary by grid and by team. Social events run their own protocol: on several grids, arriving at a dinner party exactly on time is itself the fault. Observe what the locals do, not what they say, and write down the actual offsets: this office’s standup starts 3 minutes late, every time, like clockwork. And calibrate against your peers, not your boss. On most grids, lateness is a privilege of rank, and it does not transfer down.

Then run dual clocks knowingly. For your own deliverables, pin to the stricter of the two clocks, whichever grid it came from. Reputations are lost on late deliverables, never on early ones. The local offset is for the social interface, the arrival times and meeting starts, applied deliberately at the boundary the way you apply the voltage adapter: a conversion at the interface, not a rewrite of the core.

The Request

This week, build the decode table. Five event classes on your current grid: the all-hands, the standup, the 1:1 with your manager, the customer call, the team lunch. For each, write the stated time, the observed start, and the offset. You now know more about the local scheduler than most people who grew up on it.

Then type your next deadline in public. When you hand one out, say which kind it is: “this is hard, the demo dies if we miss it” or “this is a target, tell me early if it drifts.” Watch how much friction that one sentence removes.

Tell me in the comments which grid you compiled on and the worst cross-clock incident you have caused or eaten: the meeting you sat in alone, or the four minutes that cost you a reputation. And post your office’s real standup offset. Everyone has measured it. Nobody says it.

System Library

The Talk: The Secret Powers of Time by Philip Zimbardo

The RSA Animate of Zimbardo’s research on time perspectives: how people and whole cultures weight past, present, and future differently, and how completely it drives behavior. Watch it to stop treating your grid’s clock as the reference implementation.

The Concept: Real-Time Computing

The engineering source of this post’s distinction: hard, firm, and soft deadlines, defined by the cost of a miss, not by the timestamp. The vocabulary for asking “what happens if this slips,” named precisely.

The Field Manual: A Geography of Time by Robert Levine

Levine measured the actual pace of life across 31 countries: walking speed, postal transaction time, clock accuracy. The field data proving that “on time” is a local constant, not a universal one, and that your grid calibrated you without asking.

System Status

Theory is for brochures. Engineering is for survival. If your team spans grids where 9 AM means three different things, or your deadlines keep parsing as suggestions and your punctuality as hostility, I provide Strategic Debugging and Mentoring. Review the operating parameters at weivco.com.

Elsewhere: I write about building software with AI at The Old Man and the AI, and I build Fractbox, a browser-based 3D fractal engine.