HN Theater @HNTheaterMonth

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.

https://www.youtube.com/watch?v=-5wpm-gesOY The Problem with Time & Timezones - Computerphile / Tom Scott

⬐ WelcomeShorty

Crazy funny video. Thanks.

Computerphile has a really amusing (sort of) video on the related issue of how to translate between internet time and local time zones (though they have a different opinion about the wisdom of 'leap smears' vs 'leap seconds'):

https://www.youtube.com/watch?v=-5wpm-gesOY

Note that the common-sense notion that time intervals are fixed fails when relativistic concepts are introduced. Atomic clocks get out of sync due to being in different relativistic frames (satellites vs. ground, for example). Hence designating a 'universal time' is always going to be somewhat arbitrary.

https://blog.swiftnav.com/relativistic-correction/

Hopefully the Aliens will leave the planet before the discussion gets to G11n...

"The Problem with Time & Timezones" - https://youtu.be/-5wpm-gesOY

https://en.wikipedia.org/wiki/Internationalization_and_local...

This reminds me of the Numberphile video on date and timezones. https://www.youtube.com/watch?v=-5wpm-gesOY

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: https://youtu.be/-5wpm-gesOY. My favorite video on the topic.

Here you go: https://youtu.be/-5wpm-gesOY?t=368

I'd highly recommend watching the whole video, by the way. It's really good.

⬐ idiocrat

Work in Finance.

My year starts on April 1st.

I do not want my year to start on January 1st, else I will need to work through all holidays for year-end closing.

It's clickbait.

Computerphile managed a much better title[1]: The Problem with Time & Timezones

A "(for programmers)" could be appended if needed.

[1] https://www.youtube.com/watch?v=-5wpm-gesOY

⬐ xboxnolifes

Its not click bait, the contents are what the title claim to be.

Always a classic watch https://www.youtube.com/watch?v=-5wpm-gesOY

⬐ ponsfrilus

Yes! This Computerphile's video is a must watch!

Relevant Tom Scott video: https://www.youtube.com/watch?v=-5wpm-gesOY

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: https://github.com/brave/brave-core/pull/11030.

For 10 minutes of anxiety, check out 'The Problem of Time & Timezones' from Tom Scott of Computerphile: https://youtu.be/-5wpm-gesOY. It's a fantastic summary of the issues programmers face when dealing with time :)

Sampson (Brave Team)

⬐ silisili

Thank you Sampson.

I apologize for my hasty comments. Based on the Reddit thread I had seen, it seemed most people were blaming a down server - and to a user, that's what it -felt- like too, seeing as there wasn't an app update or anything recent. I'm thrilled to hear that wasn't the case, and appreciate the explanation. Sounds like we're staying with Brave then!

⬐ jonathansampson

It's alarming how cavalier people are with spreading made-up explanations when something isn't working as expected. But we're always here and happy to chat about what's actually happening (provided there is indeed an issue, and we have it understood). Thank you for allowing us a moment to share more information; I hope the DST topic and aforementioned video on Time and Timezones wasn't too frightening, lol :)

Sampson (Brave Team)

Tom Scott's rant on time-zones is as relevant as always

https://www.youtube.com/watch?v=-5wpm-gesOY

⬐ hhebbo

yup, always

One of my favorite videos on time zone complexities: https://youtu.be/-5wpm-gesOY

Obligatory post to Computerphile episode about Timezones - a must watch for developers just starting out with Timezones

https://www.youtube.com/watch?v=-5wpm-gesOY

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."

https://youtu.be/-5wpm-gesOY

⬐ et-al

> 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?

Edit: I originally misunderstood your question. Since (in the future) 2021-11-07 02:00 is when we change to standard time, how does a library know whether to apply a -5 or -4 offset to 01:50?

The library will need to make assumptions about the inputs and it would probably stick with the original offset (one should check the source). For a human-facing interface, it'd be a good idea to raise the issue.

⬐ k_sze

This also reminds me of the post Jon Skeet wrote about using UTC: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...

Also discussed on HN back in the days: https://news.ycombinator.com/item?id=19500640

Tom Scott did a fun video of the general nightmare that timezones bring to the dev table: https://youtu.be/-5wpm-gesOY

Computerphile has a great video on this: https://www.youtube.com/watch?v=-5wpm-gesOY

Every time I see a video from Computerphile I think about the video they did on Timezones: https://www.youtube.com/watch?v=-5wpm-gesOY

Tom Scott has a great video about time and timezones on Computerphile: https://youtu.be/-5wpm-gesOY

Immediately thought of Tom Scott's Computerphile video on time & timezones:

https://youtu.be/-5wpm-gesOY

10m12s watch. Informative and entertaining.

That’s a hard question regardless of programming language. One commonly referenced YouTube video about time that explains why this is hard: https://youtu.be/-5wpm-gesOY

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.

⬐ vlovich123

No, you say "sleep until 3pm on saturday" you don't predict anything. The OS computes an exact value to wake up in when you arm. If that clock then jumps forwards or backwards or does anything weird you then recompute the expiry timeout for that timer. You can't do this in app-space but AFAIK all OSes provide a facility for you to do so.

https://developer.apple.com/documentation/dispatch/1420517-d... http://man7.org/linux/man-pages/man2/clock_nanosleep.2.html

> 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

https://www.youtube.com/watch?v=-5wpm-gesOY

Really fascinating read. It reminded me of Tom Scott's video on Numberphile, about time zones: https://www.youtube.com/watch?v=-5wpm-gesOY

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"

https://www.youtube.com/watch?v=-5wpm-gesOY

and why I will never implement datetime myself

⬐ a3n

Nobody ever got fired for using the provided datetime.

⬐ robertAngst

What is the standard for using datetime libraries?

Use the one that comes with each language, or use some UTC library?

Also somewhat related: Computerphile's video on dates and timezones. Programmers might be tempted to make similar assumptions about dates, times and timezones:

https://www.youtube.com/watch?v=-5wpm-gesOY

Reminds me of Computerphile's The Problem with Time & Timezones - https://www.youtube.com/watch?v=-5wpm-gesOY

This one: https://www.youtube.com/watch?v=-5wpm-gesOY

The Problem with Time & Timezones - Computerphile https://www.youtube.com/watch?v=-5wpm-gesOY

A fantastic overview of the headaches you'd have if you wanted to code all this.

Time Zones are already a huge PITA no matter how you slice it.

This video sums it up fairly nicely: https://www.youtube.com/watch?v=-5wpm-gesOY

I wonder if anyone has looked at the complexity¹ of maintaining timezones in software before raising as a solution for every member state decide for themselves whether to abolish or not. It will be an absolute nightmare. It's going to be hours of code audit and consulting gigs like it's 1999 (I mean Y2K).

__

¹ The Problem with Time & Timezones https://www.youtube.com/watch?v=-5wpm-gesOY

⬐ aleksei

TBH, if you've rolled your own time handling logic you were already in a special kind of hell. But time zone changes aren't that irregular, so it should be pretty straightforward for library maintainers to fix the timezones up.

I really enjoyed this.

And I think no one mentioned the very related Computerphile video yet: "The Problem with Time & Timezones " https://www.youtube.com/watch?v=-5wpm-gesOY

Same topic, equally entertaining (not AS geeky though).

Tom Scott on timezones:

https://www.youtube.com/watch?v=-5wpm-gesOY

* The Problem with Time & Timezones - Computerphile - YouTube || https://www.youtube.com/watch?v=-5wpm-gesOY

Computerphile has a wonderful video about dates that covers this subject perfectly. Mandatory viewing on my team before anybody has a problem involving dates.

https://m.youtube.com/watch?v=-5wpm-gesOY

I'll just leave this here:

Have a look at a j excellent video that explains why time algorithms are hard to sort out: https://m.youtube.com/watch?v=-5wpm-gesOY

Happy New Year from Austin!

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 https://www.postgresql.org/docs/9.2/static/datatype-datetime...

Computerphile what's wrong with timezones https://www.youtube.com/watch?v=-5wpm-gesOY

⬐ DasIch

The TZ database has versions and you could at least in theory expose that at a higher level in libraries.

⬐ nicpottier

Pretty sure pytz will hand you the appropriate timezone for a given date. There aren't version numbers after all but it can do the right thing based on when you say it is.

There is some weird behaviour due to this when trying to get a timezone without an associated date as it doesn't default to now.

Then again you probably have all sorts of DST bugs if you have places in your code that do that.

⬐ Stasis5001

Pytz handles a certain class of funkiness in TZ changes, but not the one mentioned here. Consider, a user in footopia enters a datetime 3 months from now which is saved in UTC in your database. Then footopia changes their TZ definition. The only way you could get this right is if you also know when the datetime in the database was created. You would need to tell your datetime library the datetime and _when it was created_, and pytz doesn't do that (I don't know any that do, actually).

⬐ guitarbill

You'll never get this right, even if you had all of this info, because as mjevans points out[0] to make it work you need to know:

> P) The event is at a precise internationally recognized moment (better for co-ordination globally).

> R) The event is in local time (like a lunch date) and expected to remain colloquially fixed.

In the case you mention, it's somewhat arguable that the burden of changing the colloquially fixed dates (R) falls on the citizens of footopia, in the same way as changing the time of a purely mechanical clock also would. caveat emptor.

[0] https://news.ycombinator.com/item?id=13206671

⬐ masklinn

> Pretty sure pytz will hand you the appropriate timezone for a given date.

Correct, or more precisely for a given timezone it will use the correct offset depending on the date being converted:

    >>> format_datetime(datetime.datetime(2011, 12, 15, 10, 5, 18, tzinfo=berlin).astimezone(samoa), 'full')
    Wednesday, 14 December 2011 at 23:12:18 Apia Daylight Time
    >>> format_datetime(datetime.datetime(2012, 1, 15, 10, 5, 18, tzinfo=berlin).astimezone(samoa), 'full')
    Sunday, 15 January 2012 at 23:12:18 Apia Daylight Time

>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 https://www.youtube.com/watch?v=-5wpm-gesOY

This is a very interesting video by Computerphile on this subject: https://www.youtube.com/watch?v=-5wpm-gesOY

Dealing with time-zones and daylight savings time (which countries have it and which don't) can be a very challenge and messy problem that is really easy to get wrong.

Heres a pretty good video from computerphile on the subject https://www.youtube.com/watch?v=-5wpm-gesOY

⬐ wangchow

Spring forward, fall back!

⬐ zaphar

But not every country or even every part of every country...

⬐ collyw

Won't most mainstream languages have a built in library for that sort of thing these days?

⬐ PeterisP

The libraries don't really help with some issues.

E.g. a rather trivial example of displaying a hourly graph/table of some measurement, including comparison with yesterday (because there are daily patterns of fluctuation).

DST means that some of days have 23 hours and some days have 25 hours. The libraries will help you make the relevant calculations, but now you have to make a decision wether the comparison that you make with "yesterday equivalent" of today's 11:00 is yesterday's 11:00 (23 hours ago) or yesterday's 10:00 (24 hours ago).

For another example, accounting of hours worked - you may have a person that has worked 25 hours in a single day, such events break some systems.

⬐ dcornu

They do. The problem is that the rules of DST change over time (sometimes at the very last minute https://github.com/eggert/tz/commit/868f3528a9fd60491439ce45...) and can lead to all sorts of date math bugs when comparing timestamps across timezones.

⬐ douche

A lot of them are... not great. Moment.js makes it somewhat bearable in JS, but the native stuff is hot garbage.

⬐ gregmac

Most do, but the problem is less about the library and more about understanding how to use it.

For example, if you want an event to happen in 12 hours, and it happens to be 9pm the day before daylight savings time, do you schedule it using the timezone-aware API (so it happens at 9am, which is actually 13 hours away) or 8am (which is 12 hours, but non intuitive)? What about the event that's supposed to happen every 12 hours in perpetuity?

What happens when the user/device is mobile, and crossing timezones? Which times do you use?

What happens when you're scheduling something far in advance, and then the timezone definition itself changes (as happens a few times a year) between the time you scheduled the event, and the time something actually is supposed to happen? Does the event adjust for the new definition or follow original time?

Luckily for many problem domains, the details around this don't matter too much, but this is just the tip of the iceberg with timezone challenges.

https://www.youtube.com/watch?v=-5wpm-gesOY&feature=youtu.be...

    What you learn after dealing with timezones is that you put away your code.

    You don't try and write anything to deal with this.

    You look at the people who have been there before you.

    You go to them, and you thank them *very much*, for making this open source.

    And you give them credit. And you take their code, and put it in your program.

    And you never look at it again, because there lies *madness*.

Thank you so much for giving us Moment. Your suffering has not been in vain. <3

Computerphile did an excellent overview of time zones and all their complexities in the context of programming:

https://www.youtube.com/watch?v=-5wpm-gesOY

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.

This reminds me of the excellent computerphile video https://www.youtube.com/watch?v=-5wpm-gesOY

See also: https://www.youtube.com/watch?v=-5wpm-gesOY

There is a video by Computerphile (https://www.youtube.com/watch?v=-5wpm-gesOY) which in an entertaining way explains time zone problems.

⬐ douche

That is one of my all-time favorite youtube videos... This one, and a similar one on unicode[1], are my goto exhibits when I need to illustrate to a non-technical family member how much background complexity is involved in software

[1] https://www.youtube.com/watch?v=MijmeoH9LT4

⬐ pmiller2

I would think the time zone example would go over better than Unicode, because it's less esoteric. Almost everybody deals with time zones at some point; not everybody deals with Unicode.

⬐ Piskvorrr

Surely they do. They're just not aware of it ;)

(Yes, yes, amounts to the same thing. Except when it breaks.)

https://www.youtube.com/watch?v=-5wpm-gesOY is a pretty entertaining video that talks about the various hoops developers must jump through.

⬐ douche

If you haven't seen this, you should. Quite possibly my favorite youtube video, and this channel has a number of other great clips.

⬐ com2kid

I work in embedded.

We have to do this on our own.

It is every bit as painful as it is made out to be.

A common problem that I don't see discussed much is the difference between recording when a time took place (just record and store it in UTC!) and then translating that into what the user expects to see. This is especially hard if you have information that should be grouped into "days", and a use case where the user changes time zones but may expect the same "relative to originally recorded time" to be shown when viewing past events.

A nightmare case.

Tom Scott talking about timezones and it's quirks: https://www.youtube.com/watch?v=-5wpm-gesOY

Maybe both, or none. It's complex: https://www.youtube.com/watch?v=-5wpm-gesOY

I watch Tom Scott's "The Problem WIth Time And Time Zones" from time to time just as a reminder

https://www.youtube.com/watch?v=-5wpm-gesOY

⬐ laut

It is a good video. The good thing about using a library like Kalends is that it takes into account everything he mentions about different timezones into account. Just tell it the time, date, and timezone name.

Just be careful about generalizing too much and assuming things such as: "this time will exist again tomorrow". Or "next month also has a 31st day". Or "DST is always a 3600 second difference from standard time".

Here is another article I wrote which also talks about some pitfalls of time and timezones: http://www.creativedeletion.com/2015/01/28/falsehoods-progra...

unobfuscated link: https://www.youtube.com/watch?v=-5wpm-gesOY "The Problem with Time & Timezones - Computerphile"

This video seems appropriate https://youtube.com/watch?v=-5wpm-gesOY

There is a great (humorous) Computerphile video about this topic: "The Problem with Time & Timezones" [0]

[0] https://www.youtube.com/watch?v=-5wpm-gesOY

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] https://www.youtube.com/watch?v=-5wpm-gesOY

Tom Scott has a wonderful video walking through the overwhelming complexity of timezones: https://www.youtube.com/watch?v=-5wpm-gesOY

An excellent video touching on some of the intractable aspects of our datetime-marking system's personality quirks: https://www.youtube.com/watch?v=-5wpm-gesOY

I feel like Tom Scott did a great job summing up the frustrations dealing with time (zones) in his Computerphile video:

https://www.youtube.com/watch?v=-5wpm-gesOY

The Problem with Time & Timezones - Computerphile http://www.youtube.com/watch?v=-5wpm-gesOY&feature=share