A timestamp and a date are not the same object. A timestamp is one moment on a global clock, the same instant everywhere at once. A date is a square on a local calendar. Your software stores the first. Your notice periods, your rent ledger and every deadline you are held to run on the second, and something in between has to convert one into the other.
That conversion is where records quietly disagree with each other.
The same moment can be two different days
A resident sends a message at 9:15 in the evening on August 31 from Vancouver. That is one instant. Stored as a global timestamp it is already September 1 in coordinated universal time, and an export rendered in Eastern time prints September 1 as well. Nothing failed and no error appeared. The record answers the question "what day was that" differently depending on which system you ask.
Canadian portfolios feel this more than most. Time zones and daylight saving are set by provincial and territorial legislation, so the rules are not uniform across the country. Most of Saskatchewan stays on Central Standard Time all year, and since 2020 Yukon has stayed on UTC minus seven hours year round, according to the National Research Council. A manager with buildings in three provinces is running systems whose idea of local time is not the same idea. It is the same class of problem as unit numbers that no two systems spell the same way: nothing breaks loudly, so nobody looks.
Two weekends a year, the arithmetic bends
Clocks across most of the country move forward on the second Sunday in March and back on the first Sunday in November, at 2:00 local time. One of those days is 23 hours long and the other is 25.
Any window your tools compute by adding a fixed number of seconds drifts by an hour across those two weekends. Add 86,400 seconds to Saturday at noon and you land at one in the afternoon on the March weekend, and at eleven in the morning on the November one. An hour rarely decides a hearing. It decides plenty of arguments, and it is the kind of detail nobody can reconstruct six months later.
Run the ten minute test
Take each system that records something you might one day have to prove: your management platform, your leasing inbox, your texting tool, your payment processor.
- Create one record in each between 10:00 in the evening and midnight, local time. A test message, a note to yourself, a one dollar payment.
- Tomorrow, export that record and read the date it prints. If it prints tomorrow's date, your export is not rendering in your local time.
- Find the setting that controls it. Some tools render in the account time zone, some in the viewer's browser time zone, some in the server's, and all three can be live inside one company at once.
- Check what your late fee and arrears cutoffs run on. A fee that fires at midnight server time can charge a resident who paid before midnight where they live.
Write the date down yourself
The fix is boring, and the boring part is why it works. When a date carries a consequence, put it in a note field in words at the time, not afterward: served in person, 4:40 in the afternoon local time, Tuesday September 8. That sentence survives an export, a migration and a change of software. The raw timestamp survives all three too, but it tends to arrive with its time zone stripped off and nobody left in the building who remembers which one it was.
Your systems will keep storing instants, and they should. Translating them into the day you will be held to is still your job.