Skip to content
←

필사 모드: Falsehoods Programmers Believe About Time

English
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

Introduction — The Falsehoods Genre

Software development has a famous genre of article: "Falsehoods programmers believe about X." Falsehoods about names, falsehoods about addresses, and — most notorious of all — falsehoods about time. The format is simple. List the propositions we consider "obvious," then show that each one is actually wrong.

This genre is popular because these propositions are so plausible. Who would object to "a day has 24 hours"? But that very obviousness is the trap. We engrave these assumptions into code without a second thought, that code runs fine most of the time, and then at some exceptional moment it quietly collapses.

This post picks four of the falsehoods about time that bite developers most often, and explains each with a real bug attached. The goal is not to scare you but to make you check whether an assumption like this is hiding in your own code. If you need a tool for working with time, you can compare the times of several regions side by side with this site's World Clock.

Falsehood 1 — "A Day Has 24 Hours"

This is the most fundamental falsehood. The assumption that a day is exactly 24 hours — that is, 86,400 seconds — goes wrong in several cases.

Because of daylight saving time. On the spring day when DST begins, the clock jumps forward one hour. That day is a 23-hour day. Conversely, on the autumn day when DST ends, it is a 25-hour day. So if you unconditionally compute "from midnight today to midnight tomorrow" as 86,400 seconds, you are wrong twice a year.

On top of that, in special cases where a country changes its standard time itself or crosses the international date line, the length of a day can differ even more dramatically. In fact, some regions have skipped entire dates in their history due to policy changes.

A real bug. A time-and-attendance system computed working hours as "the difference between clock-in and clock-out time." But on the day DST ended and it became a 25-hour day, an employee who worked overnight was credited with one more hour than they actually worked. Conversely, on the DST start day, they were credited with one hour less. The assumption "a day is 24 hours, a simple subtraction of two times equals elapsed time" collapsed in the face of DST. The correct approach is to convert both moments to UTC and measure the difference there. UTC has no DST, so elapsed time is accurate.

Falsehood 2 — "A Minute Has 60 Seconds"

This too is almost always true, but not always. Because of the leap second mentioned earlier.

The Earth's rotation speed is slightly irregular, so a discrepancy accumulates between atomic-clock time and rotation-based time. To correct it, an international body occasionally inserts one extra second at the end of a day. The last minute of such a day has 61 seconds, not 60.

On a day with a leap second inserted:
  23:59:59
  23:59:60   ← a time that legitimately exists
  00:00:00

Most applications never need to worry about this. But it becomes a problem in systems that handle time very precisely or do strict second-level arithmetic.

A real bug. In the past, at the moment a leap second was inserted, there was a famous incident where several large services had outages at the same time. The kernels and applications of some systems met the unexpected value "23:59:60," fell into infinite loops, or burned CPU at 100% and hung. The assumption "seconds run from 0 to 59" was buried deep in the code. After that incident, much large-scale infrastructure adopted "leap smearing" — absorbing the leap second in small pieces over a whole day. It is a strategy of never exposing a 61-second minute to the system at all.

Falsehood 3 — "The Clock Only Moves Forward"

That time flows monotonically forward is a physical intuition, but it does not apply to a computer's clock. A computer's wall clock can move backward.

The most common cause is NTP (Network Time Protocol) synchronization. A computer's local clock drifts, and NTP corrects it to the accurate time. If the local clock was ahead of reality, NTP pulls it back. At that moment, "now" becomes more in the past than a moment ago. The end of DST (setting the clock back one hour in autumn) also rewinds local time.

A real bug. A service measured request processing time like this.

start = current_wall_clock_time()
... process the request ...
duration = current_wall_clock_time() - start

Normally it worked fine. But when NTP happened to adjust the clock backward mid-processing, duration went negative. This negative value flowed into timeout calculations and metric aggregation, so some requests timed out immediately and some statistics became nonsensical. It took days to find the cause, because it was almost impossible to reproduce. The lesson is clear. To measure elapsed time, you must use a monotonic clock that never moves backward. Use the wall clock only for "what time is it now," and measure "how much time has passed" with the monotonic clock.

Falsehood 4 — "A Time Zone Is a Fixed Offset"

It is easy to think Asia/Seoul is always UTC+9 and America/New_York is always UTC-5. But a time zone is not a fixed offset — it is a set of rules that changes over time.

The biggest reason is, again, daylight saving time. A region with DST changes its offset twice a year. New York is UTC-5 in winter and UTC-4 in summer. Moreover, countries actually change their time policies for political and economic reasons. They newly adopt or abolish DST, and even change their standard time offset itself. Such changes happen more often than you would think, sometimes with only a few weeks' short notice. What holds the history of all these changes is the IANA Time Zone Database.

A real bug. A global calendar app, when storing meeting times, stored only the offset at that moment instead of the time zone name. When a user scheduled a meeting for "10 a.m. New York, three months out," the app froze the then-current offset of UTC-4 with it. But when DST ended in those three months and New York shifted to UTC-5, the stored meeting displayed at 9 a.m. wall-clock. Users showed up to meetings an hour early.

The correct approach is to store future events with the time zone name (America/New_York) rather than the offset. Then no matter how the DST rules change, the time is always recomputed to the correct wall-clock time when displayed.

Other Falsehoods — A Quick Pass

Beyond the four above, the "falsehoods about time" list has many famous entries. Let's touch a few briefly.

  • "A country uses one time zone." No. Many countries — the US, Russia, Australia — have several time zones. Conversely, some countries like China use a single time zone despite vast territory.
  • "Time zone offsets are in whole hours." No. There are 30- and 45-minute offsets, like India at UTC+5:30 and Nepal at UTC+5:45. Code that assumes offsets are whole hours breaks in such regions.
  • "Comparing two timestamps tells you the time order." Not in a distributed system. If the clocks of different servers are skewed, an event that happened later can carry an earlier timestamp.
  • "A leap year comes every 4 years." Mostly right, but there are exceptions. A year divisible by 100 is not a leap year, and among those, a year divisible by 400 is a leap year again. 2000 was a leap year, but 1900 was not.
  • "Midnight always exists." No. In some regions, 00:00 on a given date has failed to exist because of a DST transition.

What these entries have in common is that they are all propositions that are "true in most cases but have exceptions." And software bugs are always born in those exceptions.

Why We Keep Getting Fooled

At this point, let's ask a fundamental question. Why do developers get fooled by these falsehoods again and again? There are a few reasons.

First, these assumptions match everyday experience. Most of us live in environments with no DST, or with DST we do not think much about. So it feels counterintuitive that a day might not be 24 hours.

Second, these bugs hide well most of the time. A DST transition happens only twice a year, a leap second once in a few years, and an NTP clock rewind is hard to predict. So they rarely surface in tests and only strike at a specific moment in production. Hard to reproduce means hard to debug.

Third, languages and libraries leave the traps in place. The default date type in many languages readily allows a naive form with no time zone info, and does not clearly distinguish the wall clock from the monotonic clock. So the wrong choice easily becomes the default.

These three combine to give time bugs their characteristic nature: commonly introduced, rarely triggered, and hard to catch.

Habits to Avoid Being Fooled

Memorizing the list is not enough. You have to turn it into habits that avoid the traps in practice.

  • Store in UTC. Storing on a single baseline unaffected by DST and offset changes makes you less dependent on assumptions like "a day is 24 hours" or "a fixed offset."
  • Measure elapsed time with a monotonic clock. A defense against the "the clock only moves forward" falsehood.
  • Store future events with the time zone name. A defense against the "a time zone is a fixed offset" falsehood.
  • Do not hardcode time zone rules; use the IANA database. And keep it up to date.
  • Put extreme cases in your tests. Deliberately test DST transition days, 30- and 45-minute offset regions, leap-year boundaries, and the vicinity of the date line.
  • Always ask "is this an absolute moment or a calendar date?" This single question prevents many type-choice mistakes.

Conclusion

The reason the "falsehoods programmers believe about time" list keeps being passed around is that it is not mere trivia but a map of real bugs. That a day has 24 hours, that a minute has 60 seconds, that the clock only moves forward, that a time zone is a fixed offset — every one is only "true in most cases," not "always true."

The point is not to memorize these falsehoods one by one, but to understand the principle behind them. Time is not a pure physical quantity but a concept layered with human conventions, and those conventions differ by region and change over time. Accept this fact and build defensive habits — UTC storage, the monotonic clock, the IANA database — and most of these falsehoods can no longer bite your code. If you want to compare the times of several regions yourself, open the World Clock and see how these falsehoods actually show up.

References

현재 단락 (1/53)

Software development has a famous genre of article: "Falsehoods programmers believe about X." Falseh...

작성 글자: 0자원문 글자: 9,239자작성 단락: 0/53