321–330 of 334 posts
One clock for the world. If that meant you started work at 0900 UTC and finished at 1700 UTC then fine, but if you lived in a different part of the world your work day might be 0100-0900.
It'd definitely take a bit of getting used to, but as the world becomes more intertwined, timezones are a pain and constant source of confusion.
Earlier quoted context omitted.
I find it insane that there are otherwise-smart people in the world that want to abolish time zones. For example, this NY Times article. [1] In includes the most bizarre history: > A century and a half ago, time zones didn’t exist. They were a consequence of the invention of railroads. ... and goes on to describe that it's suddenly so confusing and laughable that when it was 7:00 in New York, it would now be 8:00 in…
> The result was much more fine-grained "time zones." That is true, but it did not bother anyone, because fast long-distance communication either did not exist or was very limited (e.g. smoke signals) and syncing of clocks wasn't necessary in everyday activities; for a medieval person, the idea that clocks in Vienna and Prague MUST be synchronized would be as strange as for us the idea that everyone in the same city…
Time zones were implemented in the United States in 1883. This was well after the use of telegraphs had become widespread, and after the invention of the telephone. While the telephone would not by able to make coast-to-coast calls for another few decades, the idea of communicating with people in other cities was already becoming commonplace.
My point was that the "messy" system the Times article describes would already have seemed reasonable to everyone, who already knew that people in other cities would have different working hours. What annoyed people was the "flattening" of the time zones, making it such that all the cities had to now synchronize their clocks to railway time, no matter what their local noon was. But this is the opposite of the point that the "one global time" advocate thinks he's making.
Earlier quoted context omitted.
You cannot convert a time string in the future to a timestamp. You must keep it as a string with timezone information until the time actually comes.
IMO depending on the use case, just the TZ info won't save you. Say I arrange a meeting for 4pm local time (where summer daylight savings time will be active) for July 2022.. and then the city I want to meet in gets invaded by a foreign army and changes its timezone. And cancels summer time. What time is my meeting now? I guess it needs to be a 4-dimensional coordinate, where 1 axis can slide around...
If a foreign army invades Belgium and changes its timezone, Europe/Brussels will get updated.
Earlier quoted context omitted.
> Are there really places that don't observe DST and also don't change their working hours? Huh? I'll flip the question around on you: What places are there that don't observe DST that do change working hours seasonally, especially in a coordinated way? I haven't heard of any.
The liquor store I worked in in Australia had longer hours in summer than winter.
Earlier quoted context omitted.
Good for you. Obviously the rest of the world uses phones and video calls, which is why this thread exists. You should give them a try sometime!
As I said even in the same building it's impossible to video call, because people aren't killing time all day long.
Earlier quoted context omitted.
It's a while since I read that article, so I may forget some details, but I do recall that I found it pretty stupid. It somehow assumes that it would be harder to find out what the regular working hours are in a country are than it is to find out what time it is in that country, possibly in addition to what the regular working hours are. If Google today tells me, "It's now 5PM in Singapore", with no time zones it cou…
Have you ever said "let's hang out Tuesday afternoon"? Abolishing time zones makes that a useless phrase for a large slice of the world - consider the area where the date changes in the middle of the afternoon. And which days are the weekdays? The ones where it's Monday-Friday in the morning (with Tuesday-Saturday afternoons) or where it's Monday-Friday in the afternoon (with Sunday-Thursday mornings)? This doesn't r…
Earlier quoted context omitted.
>It aims to shift the usable daylight hours to correspond with human activity. But it fails miserably at it.. Here in NYS all winter long it gets dark at 5PM. Summer, 9PM. It's useless and just causes inevitable confusion every year.
There’s nothing to be done about winter, that is the “regular” time and you live in the north. You only get the sun above the horizon for 9 hours a day in late December. The summer 9pm is the advantage of daylight savings. You get the sun up for 15 hours a day! Norther summer is great. Without daylight savings time, you’d get dark at 8pm in the summer and have an hour of “wasted” daylight before you got up. The “savi…
I'm still not sure it is worth the confusion it causes but I do have a better understanding of why it exists now. Thank you!
Earlier quoted context omitted.
As someone who routinely sets meetings for people in multiple timezones, let me say this isn't confusing. All the calendaring tools I use or am aware of, at this point, keep up with time zone correctly (or have so far). I set the meeting for, say, 10 CST, and it's clear to my colleagues in Seattle that it will be 8 for them, just as it's clear for my coworkers in DC that it'll be 11.
There are still edge cases. What if you schedule a meeting in a year's time in a timezone that doesn't have Daylight Savings Time but that government decides to add it and now the meeting is at a time that doesn't exist? But your use case it also talking about when using a tool that is specifically designed to deal with this issue. What about when you are trying to find a good time (AFAIK most calendars don't have go…
Earlier quoted context omitted.
There are still edge cases. What if you schedule a meeting in a year's time in a timezone that doesn't have Daylight Savings Time but that government decides to add it and now the meeting is at a time that doesn't exist? But your use case it also talking about when using a tool that is specifically designed to deal with this issue. What about when you are trying to find a good time (AFAIK most calendars don't have go…
Real calendar applications handle this by storing the scheduled time as GMT, and the UI adds an offset for where users are. This also solves the problem of you driving between time zones between the time that you schedule the meeting and the time that you attend it.
Your calendar can store the GMT time for lookups but it will need to recalculate this if the timezone data changes.
Furthermore it isn't as simple as "storing GMT" for repeating events. As the offset will be different for different occurrences. So you need to store the original timezone for the recurrence rule. (And see the above problem about the absolute time of a current local time being unknowable)
Earlier quoted context omitted.
Real calendar applications handle this by storing the scheduled time as GMT, and the UI adds an offset for where users are. This also solves the problem of you driving between time zones between the time that you schedule the meeting and the time that you attend it.
The problem is that the GMT time for a future event is unknowable . Timezones change based on the whims of governments. They change rarely, but they do change. Your calendar can store the GMT time for lookups but it will need to recalculate this if the timezone data changes. Furthermore it isn't as simple as "storing GMT" for repeating events. As the offset will be different for different occurrences. So you need to…
Yes, you do need to store the location of the scheduler so that you can adjust everything as appropriate, and of course you need to schedule the time the event was created. But you still only store those times in GMT.
By the way, what I’m describing is the way every AWS system does it.
Edit : Oddly, I can’t reply to your reply to this, but I already addressed the case you were talking about in this comment.