Introduction: The Persistent Problem of Time
You'd think by 2026 we'd have figured this out. We've sent probes to Mars, built AI that can write poetry, and created distributed systems spanning continents—yet time handling in software remains fundamentally, stubbornly broken. The classic "Falsehoods Programmers Believe About Time" article from over a decade ago still gets shared in programming communities because, frankly, we keep making the same mistakes. I've personally seen production outages, data corruption, and billing nightmares that all trace back to naive assumptions about time. And here's the kicker: as our systems become more distributed and our APIs more interconnected, these problems are getting worse, not better.
This isn't just academic. When your microservices span multiple cloud regions, when your users expect real-time synchronization across devices, when financial transactions need millisecond precision—time becomes your most critical and most treacherous dependency. In this guide, we'll explore why those old falsehoods persist, what new challenges 2026 brings, and most importantly, how to build systems that actually handle time correctly.
The Unkillable Classic: Why This Discussion Won't Die
Every few months, someone rediscovers that original "Falsehoods" post and shares it with a mix of horror and recognition. The comments section fills with war stories: "This caused our quarterly report to be off by millions," "We lost a day of user data during DST transition," "Our load balancers went crazy when one server's clock drifted." These aren't edge cases—they're regular occurrences in production systems.
What makes this discussion so persistent? Time is fundamentally different from other data types. It's not just a number you can increment or compare. It's a human construct layered with political decisions, astronomical realities, and technological limitations. When you store a timestamp, you're not just storing a point in time—you're storing assumptions about calendars, time zones, leap seconds, and clock synchronization. And those assumptions will eventually bite you.
I've mentored junior developers who confidently assert that "Unix timestamps solve everything," only to watch them struggle when they need to display local times or handle recurring events. The education gap is real, and the industry's move toward more distributed architectures has only widened it.
Falsehood #1: "Clocks Are Reliable and Synchronized"
This might be the most dangerous assumption of all. We treat system clocks as ground truth, but they're anything but. Clock drift is real, and it's measurable. Even with NTP (Network Time Protocol), clocks can drift by milliseconds per day. In distributed systems where ordering matters—think financial transactions or event sourcing—those milliseconds matter.
Virtualization makes this worse. Remember that Reddit comment about VM clock drift under KVM? It's not just KVM. I've seen similar issues with Docker containers, especially when the host system is under heavy load. The clock inside your container might be ticking at a different rate than the host, or it might jump forward or backward during live migration events.
Here's a practical example from my own experience: We had a microservices architecture where each service logged events with local timestamps. During an incident, we tried to reconstruct what happened by correlating logs. The timestamps were off by seconds between services, making the sequence of events impossible to determine. The solution? We switched to using a centralized time service for critical events, but even that has its trade-offs in terms of latency and availability.
Falsehood #2: "Time Zones Are Stable and Predictable"
If I had a dollar for every time I've seen code that assumes time zones never change, I could retire. Governments change time zone rules with surprising frequency. Daylight Saving Time transitions get adjusted, countries abolish DST entirely (looking at you, EU's proposed permanent time), and occasionally entire regions decide to shift their offset by 30 minutes.
Your API that serves international users needs to handle this. Storing times in UTC helps, but it's not enough. You also need to store the time zone identifier (like "America/New_York") along with the UTC timestamp if you ever need to display local time. And you need to keep your time zone database updated. I've seen mobile apps break because they shipped with an outdated time zone database and couldn't handle a newly announced DST change.
Pro tip: Don't try to maintain your own time zone database. Use established libraries like tzdata and have a update strategy. For JavaScript projects, consider Luxon over moment.js for better time zone support. And always, always test your DST transitions—both spring forward and fall back.
Falsehood #3: "Timestamps Are Unique and Monotonic"
We use timestamps as unique identifiers more often than we should. "The event happened at 2026-03-15T14:30:00.000Z, so that's our primary key." Except when two events happen in the same millisecond. Or when the system clock gets adjusted backward, and you get duplicate timestamps. Or when different parts of your system have slightly different notions of "now."
In distributed systems, you can't rely on timestamps for ordering. You need logical clocks or hybrid logical clocks. Services like Google's Spanner use TrueTime, which explicitly acknowledges uncertainty by returning time ranges rather than precise timestamps. For the rest of us, using UUIDv7 (which includes a timestamp component) or similar time-based identifiers with additional entropy can help, but they're not a complete solution.
From the Reddit discussion, one engineer shared how they used Cassandra's timeuuid type, which combines a timestamp with a MAC address and random bits to ensure uniqueness even within the same millisecond. It's a good pattern, but you need to understand that the timestamp component might not be perfectly accurate if clocks drift.
Falsehood #4: "Days Are Always 24 Hours" (And Other Calendar Assumptions)
This one seems obvious once you think about it, but it catches so many developers. Days aren't always 24 hours—Daylight Saving Time transitions give us 23-hour and 25-hour days. And don't get me started on leap seconds, which give us 61-second minutes.
But it goes deeper. Months aren't all the same length. Years aren't all 365 days. Weeks don't always start on Monday (depending on locale). If you're calculating "7 days from now" for a subscription renewal, you need to consider what "day" means in your business context. Is it calendar days? Business days? 24-hour periods?
I once worked on a billing system that calculated prorated charges based on the number of days in a month. It worked fine until February in a leap year, when someone signed up on the 29th. The code assumed all months had at least 30 days, and we ended up with division by zero errors. The fix was simple once we found it, but it took hours of debugging to realize the issue was calendar-related, not billing-logic-related.
Practical Solutions for 2026's Distributed Systems
So what should we actually do? First, adopt a defensive mindset. Assume all time-related assumptions are wrong until proven otherwise. Here's my practical checklist:
- Always store and transmit times in ISO 8601 format with time zone (e.g., 2026-03-15T14:30:00.000Z)
- Use monotonic clocks for measuring durations, not wall clocks
- Implement clock skew detection and handling in your distributed protocols
- Never use timestamps as unique identifiers without additional entropy
- Keep your time zone databases updated automatically
- Test time zone transitions, leap seconds, and leap years in your CI/CD pipeline
For API design specifically, be explicit about what time means in your endpoints. If you have a "created_at" field, document whether it's set by the client or server, and in what time zone. Consider including both UTC and local time representations if your API serves international clients. And for scheduling APIs, provide clear semantics about how recurring events handle edge cases like "the 31st of the month" in shorter months.
Tools have improved, too. Libraries like Java's java.time (based on Joda-Time's design), Python's pendulum, and Rust's chrono provide much better foundations than the old date/time classes. But they're still libraries—you need to understand the underlying concepts to use them correctly.
Common Mistakes and FAQ
"Why can't we just use Unix timestamps everywhere?"
Unix timestamps (seconds since 1970-01-01 UTC) are great for some things—they're monotonically increasing (ignoring leap seconds), they're easy to compare, and they're time zone agnostic. But they're terrible for human consumption, they don't handle dates before 1970 well, and the 2038 problem is coming. Also, they don't capture the precision you might need—milliseconds matter in many applications.
"How do I handle time in serverless functions?"
Serverless adds another layer of complexity. Functions can be cold-started, meaning their system clock might be significantly off if the container hasn't been synchronized recently. My recommendation: Don't trust the function's local clock for anything requiring precision. Use a time service API, or design your system to be tolerant of clock skew. AWS Lambda, for instance, provides the execution environment's startup time as a context variable—use that as a reference point rather than calling time functions repeatedly.
"What about blockchain and distributed ledgers?"
Blockchain systems face the same time problems, amplified. Without a central authority, how do you establish a common timeline? Most blockchains use internal logical clocks or rely on the majority of nodes agreeing on approximate time. If you're building on blockchain, you need to design your smart contracts with the understanding that timestamps are approximate and potentially manipulable by miners/validators.
Conclusion: Embracing Temporal Humility
Time handling won't be "solved" in our lifetimes. The fundamental tension comes from trying to map continuous, relativistic time onto discrete, digital systems while also accommodating human political decisions about calendars and time zones. The best we can do is approach time with humility—acknowledging its complexity and building systems that are robust in the face of uncertainty.
That Reddit discussion from years ago keeps resurfacing because each new generation of developers needs to learn these lessons. In 2026, with quantum computing on the horizon and interplanetary networking becoming a real consideration (Mars has a different day length!), we'll face new temporal challenges. But the core principles remain: question your assumptions, design for edge cases, and remember that time, like all abstractions, leaks.
Start by reviewing your current projects. Where are you making assumptions about time that might be false? How would your system behave if a clock jumped backward an hour? What happens during the next leap second? Asking these questions now might save you from a production incident later. Time, after all, waits for no one—not even programmers.
