this post was submitted on 14 Aug 2024
208 points (96.8% liked)
Map Enthusiasts
3404 readers
1 users here now
For the map enthused!
Rules:
-
post relevant content: interesting, informative, and/or pretty maps
-
be nice
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
But then we would need some method to quickly discern the relative position in the day/night cycle of a locality, perhaps some form of number to indicate the percentage of a day before or after midnight their local area is at. Then probably just add that offset so that the viewer doesn't need to do the math everytime.
The only reason why you need to do math is because you're not used to it. Once you're used to it you can just apply your local offset if you absolutely need to but otherwise you would just wake up when it's time to wake up and your UTC and you'd go to bed when it's time to go to bed in your UTC.
So timezones.
The difference is that you're not changing how time is kept. Countries can change their timezone offsets right now to screwy things like +12:45 and it changes how time is recorded and stored. If we switch to UTC, a country can just declare their official hours are shifting and nobody has to fundamentally change how clocks work.
At what time the date changes from Wednesday to Thursday? At 0:00 UTC? Ask someone in Hawaii if they would like to use different day at the morning than at the evening. "I will call you tomorrow" does it mean today afternoon, or tomorrow morning? etc.
"i will call you tomorrow" already does not define a time period. And nothing is stopping Noon from being a local time, its just that your noon in Hawaii would be UTC -10. So saying I will call you tomorrow afternoon still means I am calling in the later half of the day even in global UTC. You are just defining it with a local reference.
Currently if I want to call someone in Japan, or Australia I already cant say I will call you tomorrow afternoon, because its already tomorrow when I get up.
Yes, but these kind of long distance calls affect only a handful of people. A best before date on a food packaging or a lot of other situations where only the day is given from a date would become more complex for a lot of places, and they would affect the life of far more people.
Yes, that is the case for being in your own timezone, but what if you are dealing with someone in another country, you will need some way to know quickly what their local dayurnal situation is. Or if you are travelling, the jet lag will be compounded by confusion.
actually its easier because you just apply the UTC offset, and that is assuming its a cold call. If your setting up a call via email or chat or something like that you just say what time do you want to talk tomorrow. I work from UTC 13:00-21:00, and I see that you work UTC 07:00-15:00. How about we have our call at UTC 14:00?
doing this type of international communication gets simpler because now you dont need to convert into a local reference on both sides. Since you both work in UTC you have a standard reference and all the conversion is unnecessary.
Timezones are literally enums for UTC+offset. lambdas maybe.
But you're both doing a conversion in this case also? You're both mentally converting the UTC time into your local idea of what part of the day that is.
With time zones you don't do that mental conversion because that part is the same, you do a different conversion for the offset.
There's a conversion with either system.
That's kind of a mess even now, lots of logistical concerns, but with all the technological infrastructure we have, we could kind of do the opposite... Have watches and clocks that are always synced exactly with the day/night cycle no matter where you are. It changes a tremendous amount about how we do so many things, but it's an interesting idea.
I kinda think it might make sense to normalize using both, but at that point it feels like we may be making things worse.