title: “Falsehoods Programmers Believe About Time” still the best reminder that time handling is fundamentally broken
author: u/Digitalunicon
contenttype: redditpost
publication: r/programming
published: 2026-02-25T17:36:01+00:00
sourceurl: https://www.reddit.com/r/programming/comments/1rejwmj/falsehoodsprogrammersbelieveabouttimestill/
word_count: 937
“Falsehoods Programmers Believe About Time” is a classic reminder that time handling is fundamentally messy.
It walks through incorrect assumptions like:
- Days are always 24 hours
- Clocks stay in sync
- Timestamps are unique
- Time zones don’t change
- System clocks are accurate
It also references real production issues (e.g., VM clock drift under KVM) to show these aren’t theoretical edge cases.
Still highly relevant for backend, distributed systems & infra work.
Link: https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
Score: 1257 | Comments: 327 | Subreddit: r/programming
Top Comments
u/More-Station-6365 (492 pts):
This article has humbled more senior engineers than any code review ever could. The daylight saving edge case alone has caused more production incidents than most people want to admit.
The moment you think you have time handling figured out is exactly when a timezone update somewhere quietly breaks your scheduler at 2 am on a Sunday.
u/uniquelyavailable (225 pts):
As a programmer who works on clock systems that span the globe, I can assure you that Date and Time programming is sorcery.
u/SaltMaker23 (202 pts):
Human-readable dates can be specified in universally understood formats such as 05/07/11.
This one is the most annoying of them all
u/A1oso (67 pts):
At least Temporal is finally being rolled out, so working with time in JavaScript will be less terrible in the future.
u/dee-jay-3000 (93 pts):
The timezone mutation one catches so many people off guard. Governments have changed timezone offsets with less than 24 hours notice — Samoa skipped an entire day in 2011 — and most tz databases take weeks to propagate updates. If your system assumes timezone rules are stable constants, you are eventually going to have a very bad day in production.
u/daidoji70 (71 pts):
Imo its not "fundementally broken". Its more like time is such a weird concept that most people don't even think about and one is never even really forced to think about it outside of computer programming so there's a lot of places to trip up when developing libraries.
Then when you get into relativistic issues and coordinating time over distributed systems it becomes a series of tradeoffs that can't be reconciled and instead engineering tradeoffs have to be made. Special expertise becomes necessary.
u/elperroborrachotoo (25 pts):
Article → link to reddit → "14 years ago"
OOF. I was there, Gandalf.
u/NineThreeFour1 (18 pts):
Some of these falsehoods make me question how some programmers must be going through life not knowing that February or leap years exists (see falsehoods 2, 3, 4).
u/CanvasFanatic (14 pts):
I thought this was going to be about estimating work. What have they done to me?
u/fyndor (12 pts):
This is why noda time exists. The dev spent so much time answering time questions on StackOverflow he realized it a major issue and when he dug in it was even more complicated than he thought.
u/snowgoon_ (12 pts):
Tom Scott on The Problem with Time & Timezones
u/FlyingRhenquest (10 pts):
If you're into this sort of thing, some NIST guys did a talk at the Royal Institution a while back about precision timekeeping. They mention at one point that the banks their standards cover are required to be synchronized to within 100 nanoseconds for their transactions. That must have been a fun undertaking to implement at a global scale.
They didn't mention time much at all back in the '80's when I was in college. Given how much of a problem it is, I feel like more attention needed to be devoted to it. I don't know what they teach the kids these days, though.
I'd say it's not rocket science, but there are plenty of examples of rocket science being screwed up by bad time handling. One of the engineers at a satellite imagery company I used to work at used to tell a story about how he accidentally ran some maneuvers from his Linux account instead of the system one they usually used. He had his timezone set to a something other than the GMT one the system used (Just the TZ environment variable in his login info,) and so he ended up rotating the satellite so its solar panels weren't facing the sun. They did manage to fix it, but it took 3 days to get it back to completely normal. The same company couldn't do imaging over the international date line because it would crash processes in the ground system.
There are a lot of take-aways from that story, the main one being that if you're looking for real estate for your fortress of eviltude, right on the international dateline is a good spot to consider.
u/RiPont (9 pts):
"Time always flows forward."
That's one that gets people. Real time may or may not always flow forward, but the time according to the system does not.
u/KitAndKat (9 pts):
The date on this post is Sun Jun 17th, but it DOESN'T HAVE A YEAR!
u/EntroperZero (7 pts):
These issues are also a good study on edge cases you should handle, and edge cases you should not attempt to handle. It all depends on your application, and in most cases you can make a lot of these concerns someone else's responsibility.
u/gene_wood (12 pts):
Here's the canonical link : https://FalsehoodsAboutTime.com/
All of these captured in a white pape : https://doi.org/10.5281/zenodo.17070518
u/jhill515 (9 pts):
That's why I like robotics. The entire system can rely on local hardware clocks (on platform) for 99% of its needs. The 1% when it can't, that's because it's communicating remotely to someone.
I routinely solve this problem by treating time-sync as a mapping problem from a mathematical perspective. Sure, all the above "assumptions" are still mitigated, but if all I need to do is provide a timestamp with a disclaimer about its relative precision & accuracy compared to the autonomous platform, that's on the User. My machines do what they're supposed to do, much like how our own heartbeats keep our internal clocks running!
Disclaimer: I am in no way refuting OP's contributions. I'm merely suggesting that my strategy to "change the problem" is quite useful when you can satisfy on-platform timing and wrestle with remote time-sync.
u/golgol12 (10 pts):
You forgot this one:
- Time passes at the same rate in all locations.
General relativity sneaks up on you when you start measuring accurately enough.
u/ipompa (5 pts):
There's a good video about Time/Dates from computerphile. here
u/flyengineer (7 pts):
Disappointed no mention of leap seconds.