Here's a breakdown of the main themes discussed in the Hacker News thread about the complexities of time, along with supporting quotes:
Time is a Mess, Historically and Currently
This is the overarching theme. The inherent difficulties in representing, tracking, and reasoning about time, arising from historical inconsistencies, human conventions, and physical phenomena, are repeatedly emphasized.
- "Time is a mess. Always. The author only scratched the surface on all the issues," says Flundstrom2. This sentiment is echoed throughout the thread.
- Flundstrom2 elaborates: "Timezones; sure. But what about before timezones got into use? Or even halfway through - which timezone, considering Königsberg used CET when it was part of Germany, but switched to EET after it became Russian." illustrating the historical and geopolitical complexities.
- "Not to mention the transition from Julian calendar to Gregorian, which took place over many, many years - different by different countries - as defined by the country borders at that time..." Flundstrom2 continues, highlighting the calendrical challenges.
- wpollock quips, "But I think your point that time doesn't need to be a mess is refuted by all the points you made."
Daylight Saving Time (DST) is a Major Pain Point
DST, also known as daylight savings time, is a recurring source of frustration.
- glorbx starts the thread with: "Glad OP discussed daylight savings nightmare."
- Flundstrom2 points out a real-world scheduling paradox: "There's been at least one instance where DST was - and was not - in use in Lebanon - at the same time! Good luck booking an appointment..."
- Raphell shares a personal anecdote: "I never really took time seriously until one of my cron jobs skipped execution because of daylight saving. That was the moment I realized how tricky time actually is."
- bigiain raises the problem of scheduling across DST transitions.
The Unix Epoch and its Misconceptions
- zokier states: "It is a pet peeve of mine, but any statement that implies that Unix time is a count of seconds since epoch is annoyingly misleading and perpetuates such misconception. Imho better mental model for Unix time is that has two parts, days since epoch * 86400, and seconds since midnight, which get added together."
- charcircuit's question "How is it misleading? The source code of UNIX literally has time as a variable of seconds that increments every second." elicits the following response which further fuels the discussion surrounding the topic.
- adgjlsfhk1 simply states: "leap seconds" as the reason Unix time is not just seconds.
Time Zones are Complex and Ever-Changing
The rules governing time zones and their historical variations create significant difficulties.
- minkzilla points out the IANA's approach to managing these changes: "An IANA timezone uniquely refers to the set of regions that not only share the same current rules and projected future rules for civil time, but also share the same history of civil time since 1970-01-01 00:00+0."
Leap Seconds Pose Implementation Challenges
The insertion of leap seconds to reconcile atomic time with astronomical time introduces practical difficulties in computing systems.
- wpollock: "Leap seconds caused such havoc (especially in data centers) that no further leap seconds will be used. (What will happen in the future is anyone's guess.) But for now, you can rest easy and ignore them." This statement is arguably false, but it reflects a desire to not handle leap seconds.
- Raphell summarizes by saying "We literally have to smear time to keep servers from crashing. That's kind of insane."
- yen223 provides a detailed description of Google's "smearing" technique: "What they did instead was to 'smear' it across the day, by adding 1 / 86400 seconds to every second on 31st Dec. 1/86400 seconds is well within the margin of error for NTP, so computers could carry on doing what they do without throwing errors."
The Need for Monotonic Clocks
The reliability of system clocks and the potential for them to drift backward in time leads to a preference for monotonic time sources.
- klabb3 says, "I still use Unix flavor timestamps, but if I can I ensure monotonicity (in case of backward jumps) and never trust timestamps from untrusted sources (usually: another node on the network). It often makes more sense to record the time a message was received than trusting the sender."
- a_t48: "I’m all about monotonic time everywhere after having soon too many badly configured time sync settings. :)"
Relativity's Impact on Timekeeping
The thread touches on relativistic effects, though primarily in the context of GPS and interplanetary travel.
- smurpy: "We don’t have much trouble yet with relativistic temporal distortions, but Earth’s motion causes us to lose about 0.152 seconds per year relative to the Solar system. Likewise we lose about 8.5 seconds per year relative to the Milky Way. I wonder when we’re going to start to care."
- Bjartr drives home the importance of relativity for GPS: "GPS satellite clocks have to run fast to account for the combined relatavistic effects of moving fast and being significantly farther away from earth's gravity. Without this, they would accumulate around 11km of error per day from losing around 7microseconds per day compared to earthbound clocks."
Alternative Epochs
- pavel_lishin mentions:"other epochs work too (e.g. Apollo_Time in Jai uses the Apollo 11 rocket landing at July 20, 1969 20:17:40 UTC)." and adds "But it's kind of a wild choice for an epoch, when you're very likely to be interfacing with systems whose Epoch starts approximately five months later."
In summary, the Hacker News discussion highlights the surprisingly deep and multifaceted nature of time, moving beyond simple programming considerations to touch upon historical, political, and even relativistic complexities. While most applications can often get by with simplified models, those that require precision face a challenging landscape riddled with edge cases and potential pitfalls.