The Problem with Time & Timezones - Computerphile
Computerphile12 HN recommenders · recommended in 12 months, 2014-2026
4.4M views · 12 years ago · explainer · evergreen
Tom Scott explains for Computerphile why handling time and timezones in code is so hard, walking through a simple web app that computes how long ago something happened. It covers the quirks of timezones and calendars and ends in an exasperated rant.
It is the go-to funny, accessible explanation of why you should never implement datetime handling yourself, linked in nearly every timezone thread.
6:30You Lose an Hour of Sleep to Save $4
CGP Grey
12.6M views • 15 years ago
1:07:22Invited Talk - Guy Steele
ClojureTV
39K views • 9 years ago
40:55"Controlling Time and Space: understanding the many formulations of FRP" by Evan Czaplicki
Strange Loop Conference
69K views • 12 years ago
1:00:40Dmitry Vyukov — Go scheduler: Implementing language with lightweight concurrency
Hydra
47K views • 7 years ago
44:03Google Developers Day US - Python Design Patterns
GoogleDeveloperDay
90K views • 19 years ago
42:59"How NOT to Measure Latency" by Gil Tene
Strange Loop Conference
119K views • 11 years ago
11:25The Worst Typo I Ever Made
Tom Scott
6.4M views • 6 years ago
57:05Keynote: Begin...End?
David Beazley
9K views • 5 years ago
1:10:00The Mental Game of Python - Raymond Hettinger
SF Python
131K views • 7 years ago
1:10:05Are We There Yet - Rich Hickey
Zhang Jian
24K views • 7 years ago
1:01:37Compiling and Optimizing Scripting Languages
Google TechTalks
21K views • 17 years ago
46:10Understanding the Python GIL
David Beazley
127K views • 14 years ago
1:12:122017 ACM PPoPP Keynote: It's Time for a New Old Language
Guy Steele
7K views • 9 years ago
9:16Floating Point Numbers - Computerphile
Computerphile
2.5M views • 12 years ago
40:34Charlie Marsh: uv: An Extremely Fast Python Package Manager
Jane Street
107K views • 2 years ago
47:34RailsConf 2011: Aaron Patterson, "Double Dream Hands: So Intense!"
O'Reilly
26K views • 15 years ago
1:10:00The Mental Game of Python - Raymond Hettinger [synced version]
Tech Ma
24K views • 6 years ago
59:11How to Speed up a Python Program 114,000 times.
InfoQ
171K views • 13 years ago
1:12:27Rasmus Lerdorf - 25 Years of PHP - phpday 2019
GrUSP
3K views • 7 years ago
3:32:50JavaScript: Understanding the Weird Parts - The First 3.5 Hours
Tony Alicea
4.2M views • 11 years ago
20 comments from Hacker News
That might work for the current form of the country-specific time zones officially acknowledged by countries that exist in TLD form, but the tz database contains many more current time zones more importantly piles of historical time zones. Representing just the historical forms of currently recognized time zones in DNS would be a mess, without even getting in to those that are not associated with a country that currently exists and has a TLD. edit: This is a great video explaining a lot of the reasons why time zones are nowhere close to as straightforward as you may think: ▶ this video
They need to do it, but I hope it will be less a mess than we have on Earth with UTC. Relevant video from computerphile : ▶ this video
I have to toss this classic video on the issues with timezones and programming. The sheer amount of growing exasperation as the video goes is hilarious. ▶ this video The Problem with Time & Timezones - Computerphile / Tom Scott
This reminds me of the Numberphile video on date and timezones. ▶ this video I sometimes wonder how the code to handle all this would look like.
And just to make sure the aliens lose whatever shred of confidence they might still have in human civilisation, we should introduce them to time zones: ▶ this video . My favorite video on the topic.
Great question! Dates and times are one of the most loathed obstacles in writing software that needs to work a particular way across millions of devices situated all across the globe in different regions and time zones. In our case, we had a bit of code that aimed to measure the time until midnight/tomorrow. But when clocks change at midnight (jumping forward or backward), you can wind up with days that appear to be longer than 24 hours in length. And when a day is more than ~24hr in length, you wind up with unexpected answers to seemingly simple math equations. A bit of logic, responsible for setting up a timer, wound up scheduling numerous timers when our 'How long until tomorrow' code began returning negative numbers. That set of unintended timers locked-up the application itself. You can see our issue for the behavior here: link . For 10 minutes of anxiety, check out 'The Problem of Time & Timezones' from Tom Scott of Computerphile: ▶ this video . It's a fantastic summary of the issues programmers face when dealing with time :) Sampson (Brave Team)
Obligatory post to Computerphile episode about Timezones - a must watch for developers just starting out with Timezones ▶ this video
I'm not sure I follow (and this week, timezones and time handling are really important for my job, so I really want to understand)! If a user provides a time of 11/7/2021 1:50 AM America/New_York, how does the library determine if it's a -5 or -4 offset given that's when daylight savings time ends? I believe that's the ambiguity GP is referring to. I'm trying to align time across a few systems I work with. One provides a GMT time with an offset (clean and useful), another system reports timezones and local time, and yet another system has no idea when it moves between time zones, but reports time based on a single timezone consistently. Not dealing with multiple timezones in the past, it reminds me of Tom Scott's video on handling time and timezones, summarized at the end as roughly "Go find someone who built a library for handling times, thank them profusely, use their open source code, give them credit, and never worry about it again." ▶ this video
That’s a hard question regardless of programming language. One commonly referenced YouTube video about time that explains why this is hard: ▶ this video A reasonable first approximation of a solution would be to just check every second (or minute, or hour, depending on requirements) whether the current system time is later than the scheduled time for any pending events. Then you probably want to make sure events are marked as completed so they don’t fire again if the clock moves backwards. Trying to predict how many seconds to sleep between now and 3pm on Saturday is a difficult task, but you can probably use a time library to do that if it’s important enough... but what happens when the government suddenly declares a sudden change to the time zone offset between now and then? The predictive solution would wake up at the wrong time.
> such a reasonable, trivial task? Tom Scott has a pretty good video explaining exactly why writing code about time is not trivial: The Problem with Time & Timezones - Computerphile ▶ this video
Really fascinating read. It reminded me of Tom Scott's video on Numberphile, about time zones: ▶ this video Maybe it's the way Tom presents it, but I do get the distinct impression that (fully) dealing with time zones is an even more maddening incomprehensible quagmire of a task than rendering text as laid out in this article.
reminds of the Computerphile Tom Scott video "The Problem with Time & Timezones" ▶ this video and why I will never implement datetime myself
Also somewhat related: Computerphile's video on dates and timezones. Programmers might be tempted to make similar assumptions about dates, times and timezones: ▶ this video
I really enjoyed this. And I think no one mentioned the very related Computerphile video yet: "The Problem with Time & Timezones " ▶ this video Same topic, equally entertaining (not AS geeky though).
It does not: timezone (TZ) definitions are politicial, inaccurate, and stupid and non versioned. The problem with TZ is TZ in its core definition. 1) they always change: if you have not updated your TZ since 3 months they are probably inaccurate 2) your TZ definition maybe accurate but they may not have been applied for real in the concerned zone 3) you can have different local time for the same longitude 4) you can have different days on the same longitude ... 5) TZ are not versioned, if the TZ changed between 2 records you may have made, you have inaccurate intervals stored. We do NOT have an API to take TZ change over time in consideration. 6) CEST/DST is breaking the axiom that time is a growing monotonic function References 8.5.3 TZ in postgresql man link Computerphile what's wrong with timezones ▶ this video
>Just try to explain to everyday people just how hard the problem is A bit off topic but Computerphile / Tom Scott did an excellent video doing that ▶ this video
Computerphile did an excellent overview of time zones and all their complexities in the context of programming: ▶ this video I was quite surprised by some of the stranger rules out there, especially the regions that chose to skip a day for whatever reason. Timezones are complex! Far, far more complex than simple offsets.
There is a great (humorous) Computerphile video about this topic: "The Problem with Time & Timezones" [0] [0] ▶ this video
This will probably resonate with people here[1]. A brilliant video by Tom Scott for Computerphile, where he starts to explain what coding timezones correctly is like and by the end of it is in full polite-mini-rant-mode :D [1] ▶ this video
An excellent video touching on some of the intractable aspects of our datetime-marking system's personality quirks: ▶ this video