Every time zone on earth

Everything Deadlinewatch says to you rests on one small calculation. How many days until this deadline. That single number decides whether something reads as overdue, what the card says, how dark a day is drawn on the Forecast, and the morning your reminder arrives.

Get it right and nobody ever notices it working. Get it wrong by one day and every date in the tool becomes something you check twice, which defeats the entire point of keeping one.

Before launch I stopped building features and spent the time proving that calculation instead. This is what that looked like, because how hard a tool has been tested is a fair thing to judge it on, and almost nobody shows you.

The tool is a clock before it is anything else

It is worth being clear about how much rides on this.

“Today” is not a fact about the world. It is a fact about you and where you are. When it is Tuesday afternoon in one place it is already Wednesday in another, and a tool that resolves “today” once and hands the same answer to everybody will be wrong for a large share of the people using it, on a schedule, forever.

That is the shape of every serious date bug, and it has a nasty property. It is invisible from where the maker stands. Build and test in your own time zone and “today” always means your today. The arithmetic looks fine because you are feeding it the right day without noticing you are doing it. That is the reason I test this product against simulated users rather than my own judgment, and it is the reason the one date bug that mattered was caught early rather than in the wild.

The arithmetic cannot be checked by using the product. It has to be checked deliberately, from outside, by something pretending to live somewhere else.

What proving it actually took

Deadlinewatch’s date arithmetic now runs against every inhabited time zone on earth. From 11 hours behind universal time to 14 hours ahead, which is the full range people actually live in. At every hour of the day, because the failures cluster around local midnight. And across the specific dates when clocks jump forward and back, because a day that is 23 hours long breaks arithmetic that assumes 24.

That grid runs on the day count, on snoozing, on reminders, on repeating series, on days off, on the Lock, and on the round trip in and out of the database, where a date has to come back the same day it went in.

Underneath it, one piece of code answers “how many days until this.” One. Every screen asks the same function, and a test fails the build if a second copy of that calculation ever appears anywhere in the codebase. Your Dashboard and your Forecast cannot disagree about which deadlines are late, because there is only one answer and they both ask for it.

That is the part I would want to know as a buyer. Not that the tests pass. That the thing being tested has a single source, so passing means something.

The tests are tested too

Here is the bit I find most worth telling, because it is the step most people skip.

A test that passes tells you very little on its own. It might be checking what you think, or it might be quietly checking nothing at all, and both look identical from the outside. A grid of time zones that accidentally produced the same local day everywhere would sail through every assertion and prove absolutely nothing.

The tests carry their own controls. Before checking anything, they confirm the setup really does produce local days both ahead of and behind universal time, and that the naive way of getting a date disagrees with the correct way over 100 times. If those controls ever stop firing, the tests fail, even though nothing about the product changed. A test that cannot fail is not a test.

The same suspicion applies to the guards. Having built one that fails the build if that day-count calculation is ever duplicated, the obvious question is whether it works, and the tempting answer is that it must, because it is right there and it runs on every commit. I spent an afternoon trying to get around it instead, and closed the routes I found. Building the thing and then engineering what breaks it is the same habit pointed at my own tests.

A guard with a known way past it is worse than no guard, because you believe it. That is the sentence I would take out of the whole exercise, and it applies well beyond a test file.

Why any of this is worth a week

None of it is visible. There is no screenshot of a week spent proving that a number is right for someone 14 hours away. Nothing on screen moved, and if the work succeeded you will never have a single moment where you notice it.

That is exactly the trade. You are being asked to hand over the dates you carry in your head and stop carrying them. The only thing that makes that a reasonable thing to do is a tool that is right about what day it is, for you, where you live, without you ever having to check.

Features are easy to see and easy to copy. Every tool in the category has most of them. The part that decides whether you can actually put the week down is the part you cannot see from a marketing page, and the only honest signal available to you is whether the person who built it did the invisible work and will show you that they did. Speed, restraint and reliability come from the same place, which is a lot of unglamorous work you never see.

I did it before launch, on purpose, instead of building something you would have enjoyed looking at more. The rest of what guides those choices is written down too.

Common questions

Why does time zone handling matter so much for a deadline tool? Because “today” depends on where you are, and everything the tool says depends on “today”. Whether something is overdue, how many days remain, the shade of a day on the Forecast, the morning a reminder is sent. A tool that gets the day boundary wrong is wrong about all of it at once, and it is wrong quietly, which is worse.

How do you test time zones without users in them? By running the date arithmetic across the whole inhabited range, from 11 hours behind universal time to 14 ahead, at every hour of the day, including the dates when clocks change. The tests also verify their own setup, confirming they really are producing local days on both sides of universal time, so they cannot pass by testing nothing.

Does Deadlinewatch use my device’s time zone or a setting? Your account carries a time zone, captured when you first sign in and changeable in settings. Every date the tool shows you, and every reminder it sends, resolves against that, not against a server’s clock.

Does any of this change how I use the tool? Not at all, and that is the intent. Nothing on screen moved. What you get is the assurance that the number on your card, the color on your Forecast, and the morning your reminder arrives all come from one tested calculation rather than several that merely look alike.