There is a store that opens at 6:30 in the morning. It is one of the shops helping us test, a small counter facing the street. Between opening and 8:00 there are usually about 40 transactions. For 2 months, those 40 transactions were counted as the previous day's sales.
KAZENA Order is a register. It has a daily close. When the store shuts, it totals the day's transactions and the staff reconcile that against the cash in hand. The heading on the screen reads “today's sales”. Whose today that was, I had never decided.
The server runs on UTC. We are at UTC+8. So from 0:00 to 8:00 local, the server's calendar is still on the previous day. For a store that opens at 6:30, the 90 minutes between 6:30 and 8:00 fell onto the day before, every single day.
The store noticed before I did. After closing, they copy the register total into a paper ledger before locking the cash box. Over 2 weeks they told us 9 days did not match. The gap was always the morning, and adding it up came to exactly the morning's transactions.
I had already corrected the clock display once. Times on screen were converted to local time, and the receipts printed the right time, so the display looked right. What I had not touched was where the date gets cut. I corrected what was visible and left what was counted.
The quieter damage was the monthly close. The morning of the day the month turns lands in the previous month's total. Something sold on the morning of 1 October moves September's number. Once a month, the total shifts slightly. It was not a pleasant thing to look at.
The core of the repair was to hold 2 things separately. A transaction's time is stored as one instant, the same instant seen from anywhere. Separately from that, the business day it belongs to is stored as a calendar date cut in the store's own time zone. Totals only ever look at the second one.
Once they were separate, something else surfaced. Stores do not agree on where a day ends. A store open until 1:00 in the morning wants everything after midnight counted as the previous day's sales. So we made the start of the business day settable per store. The default is 0:00, and it can be set anywhere between 0:00 and 6:00.
We recounted the records we already had. Across 7 months there are roughly 23,400 transactions. The business day moved for 1,880 of them, and 142 daily totals changed. The amount changed on 0 transactions. Only which day they belong to changed.
After the recount, the store compared their paper against the screen once more. Over the next 2 weeks, 0 days failed to match. The morning now lands on the morning's own day, and nothing in the store's routine had to change.
If I put what I learned into one sentence: an instant belongs to the world, and a calendar day belongs to a place. The instant is the same instant seen from anywhere, but what date it is gets decided by where you are standing. The software held both of those in one value, and that is a thing one value cannot hold.
I sent it to the engineer on the KAZENA side as well. They are at UTC+7, so their offset differs from ours by 1 hour. The same code lines both of them up, and the business-day setting carries over as it is. If one product is used across borders, a mistake shaped like this is cheaper to repair in 1 place.
I estimated half a day and it took 5. Changing where the date is cut took 2 hours. The rest was recounting 7 months, entering the business-day start for each store, and sitting with the store while they looked at the 142 days that had moved. I think the reason my estimate was wrong was the memory of having corrected the display before. Once you have touched a place, you assume it is already right.