There are certain bugs that seem determined to wait until production before revealing themselves.
Date and time bugs are definitely on that list.
What's frustrating is that they rarely show up during development. Everything works on your laptop, the staging environment looks fine, automated tests are green, and then a customer from another country opens a support ticket that makes you question everything.
Over the years, I've noticed the same handful of mistakes appearing in project after project. Different teams, different tech stacks, same problems.
Here are seven date and time bugs that seem to survive code reviews and testing surprisingly often.
1. Assuming Every Day Has Exactly 24 Hours
This one sounds obvious until it isn't.
Many developers calculate "tomorrow" like this:
const tomorrow = now + 24 * 60 * 60 * 1000;
It looks perfectly reasonable.
Except not every day is actually 24 hours long.
When Daylight Saving Time starts, some days only have 23 hours.
When it ends, some have 25.
If your application schedules reminders, recurring events, subscriptions, or reports, adding 24 hours manually can eventually produce unexpected results.
Instead of adding fixed milliseconds, let your date library handle calendar calculations whenever possible.
2. Trusting the Server's Local Timezone
I've seen applications that work perfectly in development simply because the developer's machine and the production server happened to share the same timezone.
Then someone deploys the application to a cloud region on the other side of the world.
Suddenly timestamps are off by several hours.
The application isn't broken.
The assumptions are.
One of the simplest rules I've adopted is this:
Servers should think in UTC.
Users should see local time.
Trying to make your backend understand every user's local timezone usually creates more problems than it solves.
3. Forgetting About Daylight Saving Time
Even if you don't personally live in a country that observes Daylight Saving Time, your users might.
That's what makes these bugs difficult.
Imagine scheduling a meeting six months in advance.
Everything looks fine today.
Then the clocks change.
Now the meeting appears one hour early.
Nothing changed in your code.
The timezone rules changed.
This is one reason storing proper timezone identifiers like:
Europe/London
is much safer than storing fixed offsets like:
UTC+0
Offsets can change.
Timezone definitions know when they should.
4. Mixing Seconds and Milliseconds
This is probably the most common timestamp bug I encounter.
Backend:
1749047400
Frontend:
1749047400000
Both numbers represent time.
One is measured in seconds.
The other is measured in milliseconds.
Those three extra zeros are responsible for countless hours of debugging.
Whenever I'm looking at timestamps in logs or API responses, the first thing I check is how many digits they contain.
If you're ever unsure what a timestamp actually represents, converting it immediately is much faster than trying to interpret it mentally.
I built a small Unix Timestamp Converter for exactly that reason:
https://www.unixlytools.com/time-tools/unix-converter/
It has saved me more debugging time than I'd like to admit.
5. Assuming Browsers Parse Dates the Same Way
JavaScript makes working with dates look easy.
Until it doesn't.
Take this example:
new Date("2026-07-10")
Depending on the browser, locale, and runtime, parsing behavior can vary more than you'd expect.
Now imagine receiving dates from several third-party APIs, each using slightly different formats.
Things become messy very quickly.
These days I prefer exchanging dates using ISO 8601 whenever possible.
Something like:
2026-07-10T14:30:00Z
is much harder to misinterpret.
If you're working with different date formats regularly, having an ISO 8601 converter nearby can be surprisingly useful during testing and debugging:
https://www.unixlytools.com/time-tools/iso-8601-converter/
6. APIs That Don't Tell You the Timezone
This one is subtle.
Suppose an API returns:
{
"scheduledAt": "2026-07-10 09:00:00"
}
Looks harmless.
But what timezone is that?
UTC?
Server time?
User time?
Nobody knows.
Now compare it with:
{
"scheduledAt": "2026-07-10T09:00:00Z"
}
The second example leaves no room for interpretation.
Whenever an API exchanges date values, timezone information should be explicit.
If it isn't, developers are forced to guess.
Guessing is rarely a good architectural decision.
7. Database Timezone Mismatches
One database server runs in UTC.
Another runs in local server time.
The application server uses a different timezone.
The frontend assumes something else entirely.
Individually, every component behaves correctly.
Collectively, the system produces inconsistent results.
I've seen teams spend days investigating bugs that ultimately came down to different services making different assumptions about time.
The architecture that has worked best for me looks like this:
Browser
↓
Convert to UTC
↓
API
↓
Backend
↓
Database (UTC)
↓
API Response (ISO 8601)
↓
Browser
↓
User's Local Time
Every layer has one clear responsibility.
No hidden conversions.
No assumptions.
No surprises.
A Habit That Has Saved Me Countless Hours
Whenever I investigate production issues involving dates, I ask myself three questions before looking at the code.
- What timezone was this value created in?
- What timezone is it stored in?
- What timezone is the user actually seeing?
Most of the time, the bug reveals itself surprisingly quickly.
Sometimes the timestamp itself is perfectly correct.
It's the interpretation that's wrong.
When I'm working with users spread across different regions, I also like comparing multiple timezones side by side instead of calculating offsets manually.
For that, I usually use this World Timezones tool:
https://www.unixlytools.com/time-tools/world-timezones/
It's especially useful when validating schedules, support tickets, or production issues involving users in different countries.
Final Thoughts
Date and time bugs have a reputation for being difficult, but in my experience, the hardest part isn't the math.
It's consistency.
If every part of your application agrees on one source of truth—store timestamps in UTC, exchange them using ISO 8601, and convert them to local time only when presenting them to users—you eliminate a surprising number of production issues before they ever happen.
No architecture completely removes the complexity of timezones.
But a consistent one makes that complexity manageable.
And if there's one lesson I've learned after debugging more timestamp issues than I'd like to admit, it's this:
Whenever a production bug involves dates or times, never assume the timestamp is wrong.
Sometimes it's perfectly correct.
You're just looking at it from the wrong timezone.
Top comments (0)