Two Clocks In One System

You set a message to go out seven days after somebody signs up. They signed up on the 16th. It goes out on the 24th.

Nobody typed the wrong number. The schedule says seven and it meant seven.

⚠️ The alarm that wakes the job runs on your local time. The question it asks the database runs on a different one. Those two clocks are nine hours apart, and the gap between them lands as one extra day.

The short version

• Most systems keep time in UTC internally and show you local time
• A job can be scheduled in one and query in the other without anything looking wrong
• The result is a consistent one-day drift, not a random error
• The same gap makes reports count the wrong day's takings
• You do not need to fix the code to work with it — you need to know which clock each number is on

Why this is invisible

What you see	What is underneath
"Runs at 5:30am"	5:30am in your time zone
"Created on the 16th"	Stored as a moment, displayed in some zone
"Today's takings"	Today according to whichever clock asked

⚠️ Every one of those is correct on its own. The error only appears when two of them are compared, which is exactly what a scheduled job does.

One: where the offset comes from

Servers keep time in a single universal reference so that machines in different places agree. Your local time is that reference plus an offset.

UTC          the reference, no offset
Local time   UTC plus your offset

⚠️ Late-evening and early-morning local times fall on the previous day in UTC. That is the entire mechanism. Anything scheduled before your offset has passed is, to the server, still yesterday.

The practical consequence

A 5:30am local job runs at 8:30pm UTC the day before
⇒ if it asks "what is today", the answer is yesterday's date

⇒ Which is why "seven days after" lands on day eight. The job is not wrong. It is asking a question in a different time zone from the one that scheduled it.

Two: the shapes this takes in a venue

You do not write code, and you still meet this constantly.

A booking made at 1am appears on the previous day's list
A shift ending at 3am counts toward the wrong date
A report of "today" ends at midnight, not at close
A scheduled message arrives a day after you expected

⚠️ The 1am booking is the one that causes arguments, because two people looking at two screens see it on two different nights and both are reading the system correctly.

Why late-night trades meet this more than anyone

Your business day ends after midnight
The calendar day ends at midnight
⇒ every night straddles two dates

⇒ Most software was built for businesses that close before midnight. The mismatch is structural, not a fault, and it is worth naming rather than arguing about.

Three: the business day is not the calendar day

The fix that actually helps is deciding, explicitly, when your day ends.

Calendar day   00:00 to 00:00
Business day   e.g. 18:00 to 06:00 the next morning

⚠️ Write it down and use the same one everywhere. A rota built on one and a revenue report built on the other will never reconcile, and every month somebody will spend an afternoon finding out why.

What to ask your provider

"Does the daily report use the calendar day or a business day,
 and can the cut-off be set?"

⇒ Many systems have this setting and almost nobody changes it, because the default looks reasonable until you compare two reports.

⇒ On reports that nobody opens long enough to notice: the report that takes too long to open.

Four: the one-day drift is a signature

If something is consistently off by exactly one day, this is almost always why.

Off by one day, every time      - time zone
Off by varying amounts          - something else
Off by one hour, twice a year   - daylight saving

⚠️ Consistency is the diagnostic. A random error is a different problem; a reliable one-day offset is two clocks.

The check that confirms it

Take one record. Ask two people on two screens
what date it is on. If they differ by one day, you have found it.

⇒ Thirty seconds, no technical knowledge needed, and it converts a vague suspicion into something you can report precisely.

Five: we found this in our own system

We send a sequence of messages to new accounts — one on day one, day three, day seven.

The alarm that wakes the job   runs on local time
The question it asks           uses the server's date, in UTC
⇒ every message lands one day later than its name

⚠️ It had been that way since we built it and nothing had ever looked wrong, because each message still arrived, in order, at a sensible hour.

What we decided

Leave it. The messages arrive at a sensible time.
The names are off by one, and only we read the names.

⇒ Worth saying plainly: not every misalignment is worth fixing. Changing a running schedule carries its own risk, and the guest-facing behaviour was already fine. What mattered was writing down which clock each part uses, so the next person does not rediscover it.

Six: the numbers that get miscounted

Where this costs real money is in totals.

A night's takings split across two dates
A staff member's hours counted on the wrong day
An overtime threshold crossed, or not, depending on the cut-off

⚠️ The one that catches people is the overtime threshold, because a shift split across two calendar days can fall under the limit on both sides while exceeding it in reality.

⇒ Related: the hours nobody wrote down.

The reconciliation habit

Once a month: take one busy night.
Add the takings by hand from the till.
Compare to what the report says for that date.

⇒ If they differ and the difference is the early-hours trade, you have found your cut-off. Do this once and you will know your system's day boundary for good.

Seven: when you have two systems

Two systems means two clock settings, and they are rarely the same.

Booking system   business day, 6am cut-off
Accounting       calendar day, midnight
Payroll          weekly, starting Monday 00:00

⚠️ Nothing will reconcile between these, and no amount of checking the numbers will help, because the numbers are all correct against different definitions.

⇒ Fix the definitions, not the numbers. Pick one boundary and ask each provider whether theirs can be set to match.

Eight: writing times down for other people

Since two clocks exist, any time you write down for somebody else needs its zone attached.

Bad   "the report runs at 5:30"
Good  "the report runs at 5:30 local (20:30 UTC the day before)"

⚠️ This matters most when you are reporting a problem, because the person investigating will look at logs in UTC and your local time will not appear anywhere in them.

For staff instructions

"Shifts entered after midnight go on the previous night's sheet."

⇒ One sentence on the wall removes the most common version of this argument entirely.

⇒ On instructions that stay up long after they stopped being true: the note that was true when you wrote it.

Numbers worth keeping

One   Your business day cut-off, written down
Two   Which of your systems uses it, and which use midnight
Three The time zone each system reports in
Four  One reconciled night, done by hand, as a reference

⚠️ Four is the one worth the effort. A single hand-checked night gives you a fixed point to compare everything else against.

The card for the office

────────────────────────
  When a date looks wrong

  1. Is it wrong by exactly one day, every time?
     ⇒ time zone, not a mistake
  2. Does the record fall between midnight and dawn?
     ⇒ business day vs calendar day
  3. Two screens, two dates?
     ⇒ two systems, two cut-offs

  Write the zone next to every time you report.
────────────────────────

Common objections

"Our system is set to local time"

⚠️ The display is. What it stores and what it compares may not be, and those are the parts that produce the drift.

"It's only one day"

⇒ One day on a message is cosmetic. One day on a night's takings moves money between two months, and at a year end that is a real problem.

"We'd have noticed"

⚠️ It is consistent, which is exactly why it goes unnoticed. Nothing ever looks broken — everything just sits one column to the left.

"Just change the server time"

⇒ Tempting and usually wrong. Servers are kept on the universal reference deliberately; changing it fixes one report and breaks several others.

"Our accountant would have said"

⇒ They would see a total that balances against itself. The split between two dates is invisible unless somebody compares the report to the till for one specific night.

What to do this week

One   Write down when your business day ends.
Two   Ask each system which cut-off it uses.
Three Hand-check one busy night's takings against the report.
Four  Put the after-midnight rule on the wall for staff.
Five  Add the zone to any time you write down for somebody else.

Summary

• Systems keep UTC inside and show local time outside
• A job scheduled locally but querying in UTC drifts by exactly one day
• Consistency is the diagnostic — random errors are something else
• Late-night trade straddles two calendar dates structurally
• Decide your business day cut-off and make every system match it
• Not every misalignment needs fixing; all of them need writing down

Nothing looks broken when two clocks disagree. Every number is correct, and every number is answering a slightly different question.