Exploring 120 years of timezones (2021)
blog.scottlogic.com
blog.scottlogic.com
Even more amusing, the time being fixed length days is definitionally not the norm. Is why the Pacific Northwest is miserable right now. Sun is barely up by 8, and largely down by 5 in the evening. Moving the agreed offset for when we should be awake, as we will do in a couple of weeks, does little to help.
And I want to double down on how I worded that. I often see it proposed that we should all move to UTC or some such, but just change when working hours are. But, largely, that is exactly what daylight saving's time is. Yes, it is couched in silly phrasing of "saving daylight," but it is functionally the same as everyone agreeing to move school hours by an hour.
I will also double down on my silliest of hot takes. With computers in control of most clocks, I think the problem with DST is that it moves everything by an hour. We could, with today's technology, move to something where the clock moves +10 minutes for 6 months and then -10 minutes for 6 months every year and nobody would even really notice.
True, so far. But the world becomes a little more global every year, which makes the time zone friction grow.
My guess is that using both local and UTC time will become very common within 1-2 decades. As in "The raid starts at 11:00 PST/20:00 UTC".
In an organization where people are accustomed to indexing their activities to other people who live in a different time zone, it’s actually easier to use the most common time zones than it is to switch everyone to UTC. When using UTC, you have to do the mental gymnastics twice. You first have to relate your own time zone to UTC, and second relate your audience time zone to it. But what happens in practice is that you quickly learn what times in your local time zone correspond to movements of the day in your peer time zones. And because everybody has the same mental model, it’s easier (and less error prone) to just to use local time zones.
I find I'll often try and use relative times in conversation, e.g. "after the stand-up" or "at the top of the hour" rather than specifying a wall clock time.
But the more timezones the participants are in, the harder this approach gets.
Moscow changed after that to 2 hours, 31 minutes and 19 seconds for a few years before aligning with a ‘whole hour’ timezone. Fascinating - thanks for sharing!
It was Sunday, 10/13. I asked what time it was in London:
It is currently 1:39 PM MST. As GMT timezone is 7 hours behind MST, the current time in London is 6:39 AM GMT on Sunday, October 13, 2024.
Well, no, it's not.So I started grilling it on simple math ("What is 13:39 plus seven hours") and the real offsets of the time zones, and it would respond correctly, and then I'd ask for the current time again, it'd apologize profusely, and give me some B.S. calculations right on the same line!
I started inquiries about other places, like NZ and across the International Date Line, and it was spectacularly wrong. Some places like PDT it was OK. And it was repeatedly getting tripped up and apologizing and immediately supplying the wrong info again.
I was not trying to trick it; I was not going into ambiguous situations or half-hour zones. My locale doesn't observe DST, but it was clearly adapting for MST vs. DST zones.
The other comical thing was that Gemini would sometimes refuse outright to give the current time, referring me to other methods, as if there were some security blocks on that query. But only sometimes!
I simply must conclude that time zones are one of the most difficult programming problems. And I don't know how LLMs do time/date calculations. But Gemini clearly has a long way to go from these simple math confabulations!
For your example, the WolframAlpha query "time in London at 1:39 pm MST on October 13" returns the correct answer, "9:39:00 pm BST | Sunday, October 13, 2024"[1].
While WolframAlpha's natural language processing is hit-or-miss, its responses clearly state assumptions made in the face of ambiguity. In this example:
Assuming "MST" is a named time zone
Assuming "time" is referring to a calendar computation
Assuming month/day
Assuming Mountain Time (United States; no observed DST rule)
Assuming London (United Kingdom)
[1] https://www.wolframalpha.com/input?i=time+in+London+at+1%3A3...It seems that WolframAlpha is venerable and stable. I first heard of it long, long ago. (Was it only released in 2009? Seems older.)
It must have amazing staying power. It seemed like a quite powerful tool. Why is it such a well-kept secret?
But the visualisation was made around Jul 2021, so it avoids those changes (but also the more recent ones): https://github.com/colineberhardt/timezone-viz
https://www.npr.org/2024/04/09/1243405460/space-news-moon-na...
Exploring 120 Years of Timezones - https://news.ycombinator.com/item?id=28537438 - Sept 2021 (9 comments)
Yes, there are a lot of weird often politically-motivated time zones out there but for the most part it works
[0] https://www.npr.org/sections/parallels/2013/11/30/244995264/... [1] https://imgur.com/source-http-wp-me-poxsk-pq-8IFLFoJ
Sure there are other ways we could communicate offsets, days, whatever, but having everyone on the same daily schedule and just adjusting the schedule itself keeps it simple for most of the population.
Until we colonize Mars obviously… actually even the Moon has different G field so a different flow of time.