Imagine you buy a used car. You shake hands on Monday, but the money leaves your account on Wednesday, and that's the day the keys and the papers become yours. For two days, you've agreed to the deal but nothing has actually moved.
Buying a share works the same way. When you click "buy", you've agreed a price. The share isn't yours yet, and the seller hasn't been paid. The actual swap happens a little later, on a day called the settlement date.
I spent October building MarketClock, a tool whose job includes working out that date for 30 stock exchanges. I thought it would be the easy part. It wasn't, and the reasons are surprisingly human.
T plus one, T plus two
Traders write settlement as T+1 or T+2. T is the trade date, the day you clicked. The number is how many business days later the money and the shares swap.
In the United States today it's T+1: buy on Monday, settle on Tuesday. In London it's T+2: buy on Monday, settle on Wednesday.
That sounds like simple arithmetic until you remember the word business. A business day is a day the market is open. Weekends don't count. Holidays don't count. And countries don't all take the same holidays.
A Christmas trade
Here's the example that convinced me this was worth building properly.
Say a fund places an order on Wednesday, 23 December 2026, that involves both New York and London. It's on a two-day cycle, so it needs two days on which both markets are open.
- Thursday 24 December. Christmas Eve. Both markets open, though both close early. It counts. One day.
- Friday 25 December. Christmas Day. Both closed.
- Saturday 26 and Sunday 27. The weekend.
- Monday 28 December. New York is open. London isn't: Boxing Day fell on a Saturday, so the holiday moves to Monday. It doesn't count, because London has to be open too.
- Tuesday 29 December. Both open. Two days. That's the settlement date.
If you'd counted on your fingers you'd probably say Monday the 28th. A spreadsheet that only knows American holidays would say the same. It would be wrong by a day, and in finance a day means someone's money sits somewhere it shouldn't, or a trade fails and has to be fixed by hand.
Also readCybersecurity Trends: Protecting Data in the Digital Age
HolidayOps: Building a Working Days API for 250 Countries
The rule changed while nobody was watching
The second surprise was that the number itself moves.
Until May 2024, the United States settled on T+2. On 28 May 2024 it switched to T+1. The UK has announced it will make the same change in October 2027.
Now picture a back office checking a trade from 2023. If their software only knows today's rule, it says T+1, and it's wrong, because that trade was made when the rule was T+2. Old trades come up constantly: audits, disputes, tax reports, a client asking why their money arrived when it did.
So in MarketClock, a settlement rule isn't just a number. It's a number with a start date and a link to the official announcement. Ask about a 2020 trade and you get T+2. Ask about last week's and you get T+1. And under every answer it shows which rule it used, so you can click through and read it yourself.
Not everyone agrees what day it is
The last piece is time zones, and it's the one that catches even careful people.
When it's 9 p.m. on a Friday in New York, it's already Saturday morning in Tokyo. So "is the market open today?" has no single answer. Each exchange has its own "today", and MarketClock reads every market's date in that market's own time zone before asking anything else.
It sounds obvious written down. In code, it's very easy to ask "what's today?" once, using the server's clock, and then apply that one date to every market in the world. I nearly did.
What it taught me
Building this changed how I think about dates in any software, not just finance. Three habits stuck.
A date rule has a history. Weekends move, settlement cycles shorten, holidays get added. Store the rule with the day it started, not just the rule.
Count days the way the business does. "Two days later" almost never means two calendar days. Ask whose days, and which ones count.
Show your working. When a tool can say not just "Tuesday" but "Tuesday, because London was closed on Monday, under this rule, from this source", people stop double-checking it by hand. That trust is the whole point.
If you've ever wondered why money takes "a couple of days" to move, now you know: somebody, somewhere, is counting the days that count.
The full build, the architecture, the data checks and the mistakes, is in the MarketClock case study.
Up next
Keep reading.
01The Weekend Is Not a Constant
Why 'is this a working day?' breaks so much software: weekends that differ by country and change over time, holidays that follow the moon, time zones that disagree about today, and the habits that kept my own date logic honest while building HolidayOps.
5 minThe Engineering Logs
02The Discount That Knew You Were Hesitating: Rule-Based Personalisation in an Online Pharmacy
How Zovita+ turns browsing into personal discounts without a machine-learning model: one visitor key for guests and customers, interaction counters, six offer rules, one pricing function for the bag and the charge, offers locked and redeemed once at checkout, guest-to-account merging, A/B tests, and the edge cases that shaped it.
10 minThe Engineering Logs
03One Seat, Two Buyers: Race Conditions, IDOR and Keys in a Cinema Booking System
How BookMyMovie makes sure one cinema seat is never sold twice, a guessed booking number shows nothing, and a leaked or missing key can't quietly break tickets: row locks, lock order, a NULL-tolerant unique key, status compare-and-set, idempotency, IDOR scoping, HMAC tickets, captcha step-up, and the bugs that still got through.
11 minThe Engineering Logs
04The Last Mango Problem: Race Conditions in a Real Marketplace
What happens when fifty people try to buy the last item, use a single-use coupon or book a nearly full pickup window at the same instant, the MySQL snapshot detail that almost overbooked a stall, and the quieter races that hide in stock forms, restocks and payments.
10 minThe Engineering Logs
05MarketClock: A Trading Calendar That Shows Its Work
How I built MarketClock on my own: a Flask and Next.js app that tells traders and back offices whether 30 stock exchanges are open, when they close early and when a trade settles, and that links every fact it stores to the page it came from.
9 minThe Engineering Logs
06RAG Retrieval Strategies on a 50k-Document Dataset: BM25 vs Dense vs Hybrid
How BM25, dense embeddings and hybrid search (RRF) behave on a 50k-document RAG corpus: working code, honest trade-offs, and when each one actually wins.
11 minThe Engineering Logs
