Part 3 of 8 in the series Time in Software, Done Right
"Submit by June 5th."
Sounds clear, right? Everyone knows what June 5th means.
Except... they don't. And if you build a system around this requirement, you're setting up your users to fail.
This article is about deadline fairness — and why most deadline definitions are technically broken.
The Problem in One Sentence
If a deadline is defined in a way that users cannot objectively act correctly, the problem is not the user — it's the deadline.
A user shouldn't need to guess what timezone the server is in. They shouldn't need to submit "just to be safe" hours before they think the deadline is. They shouldn't lose because of ambiguity they can't control.
What's Missing from "June 5th"?
When someone says "the deadline is June 5th", what do they actually mean?
- June 5th at 00:00? (start of day)
- June 5th at 23:59? (end of day)
- June 5th at 17:00? (end of business hours)
- Some other time?
And more importantly: in which timezone?
- The user's timezone?
- The server's timezone?
- The organization's timezone?
- UTC?
"June 5th" contains none of this information. It's a Local Date — and as we established in Article 1, a Local Date is not a moment.
The Three Timezones in Every Deadline
When a deadline involves a user and a server, there are (at least) three timezones in play:
1. User Time
Where the user physically is. A user in Sydney sees their clock, their calendar, their "June 5th".
2. Server Time
Where the server runs. AWS us-east-1, Azure westeurope, a data center somewhere. The server has its own clock.
3. Organization Time
The business context. A company headquartered in Vienna might define all deadlines in Europe/Vienna, regardless of where users or servers are.
When someone says "June 5th", which of these three do they mean?
Usually: nobody knows. And that's the problem.
A Real Scenario
Let's trace through what happens with an ambiguous deadline:
- Business requirement: "Users must submit by June 5th"
-
Developer interprets: "End of day UTC" → stores
2026-06-05T23:59:59Z - Frontend displays: "Due: June 5th" (no time, no timezone shown)
- User in New York: Sees "June 5th", submits at 11:00 PM on June 5th local time
-
Server receives: The request at
2026-06-06T03:00:00Z(New York is UTC-4 in June) - Result: Rejected — the UTC deadline has already passed
The user submitted on June 5th in their timezone. They did everything right from their perspective. But they failed because "June 5th" meant something different to the server.
Now imagine this is:
- A tax filing
- A university application
- A legal submission
- A grant proposal
The stakes are real. The ambiguity is unacceptable.
"End of Day" Doesn't Help
Sometimes people try to fix this by saying "end of day June 5th" or "by end of business June 5th".
This doesn't solve anything:
- End of day — whose day? What time? 23:59? 23:59:59? 23:59:59.999?
- End of business — whose business? What timezone? What if it's a holiday?
You've just replaced one ambiguity with another.
The Only Fix: Be Explicit
A technically correct deadline has three components:
- Date — June 5th
- Time — 23:59 (or 17:00, or whatever makes sense)
- Timezone — Europe/Vienna (or the user's timezone, explicitly stated)
Example of a clear deadline:
"Submit by June 5th, 2026 at 23:59 Europe/Vienna"
Now there's no ambiguity. Users in any timezone can convert this to their local time. The system can enforce it precisely. Everyone knows exactly when the deadline is.
But What If We Want User-Local Deadlines?
Sometimes the business intent really is: "Each user has until the end of June 5th in their own timezone."
That's a valid requirement! But it's a different requirement — and it needs different handling:
- Capture the user's timezone (or let them choose)
- Store the deadline as: Local Date + User's Timezone
- Evaluate per user: Convert their timezone's "end of June 5th" to an Instant, compare to now
This is more complex, but it's honest. You're explicitly saying "the deadline is local to each user" rather than pretending a global deadline is local.
What Systems Must Enforce
If you're building a system that handles deadlines, here's what you need:
At Definition Time (when creating the deadline)
- Require a time, not just a date
- Require a timezone (or default to a clearly documented one)
- Reject incomplete definitions — don't guess
At Display Time (when showing the deadline)
- Show the full datetime with timezone at least once
- Optionally show converted to user's local time ("June 5th 23:59 Vienna = June 6th 07:59 your time")
At Evaluation Time (when checking if deadline passed)
- Convert everything to Instant (UTC) for comparison
- Use the stored timezone, not the server's timezone
- Log the exact Instant of submission for disputes
When Developers Must Push Back
Sometimes you receive a requirement like "deadline is June 5th" and you know it's incomplete.
Push back. Ask:
- "What time on June 5th?"
- "In which timezone?"
- "Should users in other timezones get the same absolute deadline, or the same local experience?"
If the business can't answer these questions, the deadline isn't defined yet — and you shouldn't build it.
Implementing an ambiguous deadline doesn't make you fast. It makes you responsible for the bugs.
The Fairness Test
Here's a simple test for any deadline in your system:
Can a user, acting in good faith, always determine whether they've met the deadline?
If the answer is "no" — if a user could submit on what they believe is the correct day and still fail because of timezone confusion — the deadline is broken.
Fix the definition, not the user's expectations.
Key Takeaways
- "June 5th" is not a deadline — it's an incomplete specification
- Every deadline needs: date + time + timezone
- There are (at least) three timezones in play: user, server, organization
- "End of day" and "end of business" are just as ambiguous as bare dates
- User-local deadlines are valid but need explicit handling
- If users can't determine whether they've met the deadline, the deadline is broken — not the user
Next up: Instant vs Local — When UTC Helps and When It Hurts — the core model for storing time correctly.
Top comments (0)