6 ms·

Store the gps coordinates of the location for the meeting instead, along with the desired local time and local date.

by codetrotter 3y ago

jvanderbot 3y ago
But the local time would change according to GP's comment.
- codetrotter 3y ago
  The top level comment said > specify a meeting in London, on July 1st 2030, at 6pm local time - no matter what happens to UK timezones between now and then GPS coordinates + local date and local time will preserve “a meeting in London, on July 1st 2030, at 6pm local time” in the desired way
  - jvanderbot 3y ago
    How: 6PM local time could mean Zulu+6 or Zulu+3 or anything else if local timezone offset changes via legislation. The best way to do it would be to say "X seconds from the time this message was sent"
    - avianlyric 3y ago
      > 6PM local time could mean Zulu+6 or Zulu+3 or anything else if local timezone offset changes via legislation. That’s the point. Normal people think about time based on their local time. If they agree to meet someone at 3pm on a day in the future, that normally means turning up on that day when a local clock on that day reads 3pm. If local time changes offset from UTC, then the meeting implicitly also changes. I’ve personally yet to meet someone that reschedules all their appointments every time day light saving (or the inverse) rolls around. Just make sure their appointment times in UTC don’t change.
    - noselasd 3y ago
      "X seconds from the time this message was sent" would certainly not hit 6PM local time if the local timezone offset changed - unless you also update X every time it does.
    - kelnos 3y ago
      +6 or +3 is irrelevant to the scheduler when they're setting the meeting time: they want it to be 6pm regardless of any time zone changes in the future. So they deliberately do not store the UTC offset with that time. They only store the geographic location. Then when the meeting time is approaching, the software can figure out what time zone (and UTC offset) applies, after taking account any time zone changes that have taken place in the intervening years, and appropriately set reminder notifications. If they were to store "X seconds from the time this message was sent", then any time zone change would likely make it not fall at 6pm on the target day, so that's not what they'd want.
- wrs 3y ago
  The point is that the local time would not change, even though the offset between UTC and local did change.
  - jvanderbot 3y ago
    I see. The problem is there is no difference between local time and "offset from UTC", right?
    - codetrotter 3y ago
      > there is no difference between local time and "offset from UTC" The difference is between applying the UTC offset for a future event using present rules. What we are saying is you should not do that because the rules can change. I ask you today that we meet at 3PM on January 24th in 2026, at the train station in Berlin. In my paper calendar book for I mark the date January 24th 2026 with the following note: “meet jvanderbot at 3PM at the train station in Berlin”. I carry this book with me for the next few years. Meanwhile, you decide to be modern so you store a note about the meeting in a database. In doing so, you convert the information into a UTC offset for that future time. But you are using current rules for today, which may change. And then when the day arrives, there has been political changes in the meantime that made it so that the utc offset is different. Because you converted to utc offset ahead of time, your representation of the time no longer maps to “3 PM” but instead to let’s say “4 PM”. I show up at 3 PM local time, as we had agreed. But you are nowhere to be seen because in your digital calendar the meeting appears to be for “4 PM”. This is what we mean when we are talking about the problem with converting a local time to a UTC offset a long time ahead.
    - kelnos 3y ago
      Local time has no notion of a UTC offset. Local time is just "9am on August 31, 2024". It's up to the application's implementation details to pair it with a physical location (e.g. some lat/long in London). The app would then have to (as the event date approaches) resolve that into something more computer-clock-understandable; that is, it would have to say "this lat/long is located in timezone XYZ, which has offset ### for that date", so it could tell the OS's notification service to pop up reminders at the appropriate times.
- stouset 3y ago
  That seems to be in line with what GP wants.
  - jvanderbot 3y ago
    I see. I misunderstood!
isbvhodnvemrwvn 3y ago
This limits your meetings to surface of earth, what if I want to meet with you on Mars?
- dotancohen 3y ago
  Even on the surface of the Earth there could be ambiguity. Some places have moved up to four meters in GPS coordinates after an earthquake. In Amsterdam that could be the difference between a war memorial and a brothel.

Store the gps coordinates of the location for the meeting instead, along with the desired local time and local date.

jvanderbot 3y ago

But the local time would change according to GP's comment.

codetrotter 3y ago
The top level comment said > specify a meeting in London, on July 1st 2030, at 6pm local time - no matter what happens to UK timezones between now and then GPS coordinates + local date and local time will preserve “a meeting in London, on July 1st 2030, at 6pm local time” in the desired way
- jvanderbot 3y ago
  How: 6PM local time could mean Zulu+6 or Zulu+3 or anything else if local timezone offset changes via legislation. The best way to do it would be to say "X seconds from the time this message was sent"
  - avianlyric 3y ago
    > 6PM local time could mean Zulu+6 or Zulu+3 or anything else if local timezone offset changes via legislation. That’s the point. Normal people think about time based on their local time. If they agree to meet someone at 3pm on a day in the future, that normally means turning up on that day when a local clock on that day reads 3pm. If local time changes offset from UTC, then the meeting implicitly also changes. I’ve personally yet to meet someone that reschedules all their appointments every time day light saving (or the inverse) rolls around. Just make sure their appointment times in UTC don’t change.
  - noselasd 3y ago
    "X seconds from the time this message was sent" would certainly not hit 6PM local time if the local timezone offset changed - unless you also update X every time it does.
  - kelnos 3y ago
    +6 or +3 is irrelevant to the scheduler when they're setting the meeting time: they want it to be 6pm regardless of any time zone changes in the future. So they deliberately do not store the UTC offset with that time. They only store the geographic location. Then when the meeting time is approaching, the software can figure out what time zone (and UTC offset) applies, after taking account any time zone changes that have taken place in the intervening years, and appropriately set reminder notifications. If they were to store "X seconds from the time this message was sent", then any time zone change would likely make it not fall at 6pm on the target day, so that's not what they'd want.
wrs 3y ago
The point is that the local time would not change, even though the offset between UTC and local did change.
- jvanderbot 3y ago
  I see. The problem is there is no difference between local time and "offset from UTC", right?
  - codetrotter 3y ago
    > there is no difference between local time and "offset from UTC" The difference is between applying the UTC offset for a future event using present rules. What we are saying is you should not do that because the rules can change. I ask you today that we meet at 3PM on January 24th in 2026, at the train station in Berlin. In my paper calendar book for I mark the date January 24th 2026 with the following note: “meet jvanderbot at 3PM at the train station in Berlin”. I carry this book with me for the next few years. Meanwhile, you decide to be modern so you store a note about the meeting in a database. In doing so, you convert the information into a UTC offset for that future time. But you are using current rules for today, which may change. And then when the day arrives, there has been political changes in the meantime that made it so that the utc offset is different. Because you converted to utc offset ahead of time, your representation of the time no longer maps to “3 PM” but instead to let’s say “4 PM”. I show up at 3 PM local time, as we had agreed. But you are nowhere to be seen because in your digital calendar the meeting appears to be for “4 PM”. This is what we mean when we are talking about the problem with converting a local time to a UTC offset a long time ahead.
  - kelnos 3y ago
    Local time has no notion of a UTC offset. Local time is just "9am on August 31, 2024". It's up to the application's implementation details to pair it with a physical location (e.g. some lat/long in London). The app would then have to (as the event date approaches) resolve that into something more computer-clock-understandable; that is, it would have to say "this lat/long is located in timezone XYZ, which has offset ### for that date", so it could tell the OS's notification service to pop up reminders at the appropriate times.
stouset 3y ago
That seems to be in line with what GP wants.
- jvanderbot 3y ago
  I see. I misunderstood!

isbvhodnvemrwvn 3y ago

This limits your meetings to surface of earth, what if I want to meet with you on Mars?

dotancohen 3y ago
Even on the surface of the Earth there could be ambiguity. Some places have moved up to four meters in GPS coordinates after an earthquake. In Amsterdam that could be the difference between a war memorial and a brothel.