6 ms·

I think you want it more specific than a timezone. For example, instead of London, suppose you wanted to meet in Glasgow, Scotland, on July 1st 2030, at 6pm lo

I think you want it more specific than a timezone. For example, instead of London, suppose you wanted to meet in Glasgow, Scotland, on July 1st 2030, at 6pm local time. Currently, Glasgow in is timezone Europe/London. However, it is not unimaginable that in that time, Scotland could hold another referendum on independence and either join Central European Time, or create Scottish Standard Time.

jvanderbot 3y ago
And so, you want a probabilistic time estimate based on the likelihood of that passing?
- codetrotter 3y ago
  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.
- toast0 3y ago
  I think it's reasonable to estimate the future time based on the current published rules. You don't need to guess at the probability of future published rules, but you do want to have sufficient information to reevaluate the published rules. This is why storing UTC dates for future events is insufficient: if the event is actually specified in local time, the date is incorrect when the time zone rules are changed. But storing the time zone is insufficient if the time zone that applies to the event also changes; you also need to store enough information to reevaluate which time zone is applicable. Of course, it can be difficult to gather this information in a user friendly way, so you know, compromises.
layer8 3y ago
The problem is that we don’t know what the timezone identifiers for hypothetical future timezones will be. Meaning, there would be no automated way to associate those future-date-time values with the correct timezone once the new timezone is added to the tz database. One could imagine using geo coordinates or similar, but the mapping from those to timezones (or from/to zip codes or area codes) is already not precisely defined. If you use city names, those might also be split/merged (Berlin) or renamed (Constantinopel).
- deleted 3y ago
  [deleted]
- mikequinlan 3y ago
  >there would be no automated way to associate those future-date-time values with the correct timezone You could develop a way to specify a location and indicate that you mean 'local time' at that location.
  - zaxomi 3y ago
    And then they change the calendar. (It has already happened in several regions when changing from Julian to Gregorian calendar. You don't know what calendar will be used at that region in the future)
- chaz6 3y ago
  If you use coordinates, make sure to take into account continental drift. You could use a plate-local coordinate system (e.g. British National Grid for Great Britain) so you only need to take into account deformation. There is actually a good read on this at https://www.ordnancesurvey.co.uk/blog/is-britain-on-the-move https://www.ordnancesurvey.co.uk/blog/is-britain-on-the-move
  - crooked-v 3y ago
    What about storing current geo coordinates and a timestamp of when they were recorded? I feel like that should be enough for a theoretical future system to adjust mapping for continental drift.
ilyt 3y ago
2030-07-01T18:00:00~Scotland/Glasgow ?
lmm 3y ago
> However, it is not unimaginable that in that time, Scotland could hold another referendum on independence and either join Central European Time, or create Scottish Standard Time. Or be in the middle of a political dispute, with different times being used depending which side one is on, like Xinjiang. So just knowing the place and local time isn't enough.
pizzafeelsright 3y ago
Suddenly, specifying noon on the third Tuesday on the second full moon after the summer equinox makes sense.
- runarberg 3y ago
  Solar noon or clock noon? What happens if the full moon is on Tuesday? Will that Tuesday count towards the third? Even if the full moon is at 23:59 (23:59 in which timezone)? Do you use solar equinox, or the Julian equinox, or the Gregorian equinox? I think you need to be more specific here.
  - joquarky 3y ago
    I wonder what the downsides would be in a time model that is indicated by a normalized global value for the current longitude where the sun is at meridian.

jvanderbot 3y ago

And so, you want a probabilistic time estimate based on the likelihood of that passing?

codetrotter 3y ago
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.
toast0 3y ago
I think it's reasonable to estimate the future time based on the current published rules. You don't need to guess at the probability of future published rules, but you do want to have sufficient information to reevaluate the published rules. This is why storing UTC dates for future events is insufficient: if the event is actually specified in local time, the date is incorrect when the time zone rules are changed. But storing the time zone is insufficient if the time zone that applies to the event also changes; you also need to store enough information to reevaluate which time zone is applicable. Of course, it can be difficult to gather this information in a user friendly way, so you know, compromises.

layer8 3y ago

The problem is that we don’t know what the timezone identifiers for hypothetical future timezones will be. Meaning, there would be no automated way to associate those future-date-time values with the correct timezone once the new timezone is added to the tz database. One could imagine using geo coordinates or similar, but the mapping from those to timezones (or from/to zip codes or area codes) is already not precisely defined. If you use city names, those might also be split/merged (Berlin) or renamed (Constantinopel).

deleted 3y ago
[deleted]
mikequinlan 3y ago
>there would be no automated way to associate those future-date-time values with the correct timezone You could develop a way to specify a location and indicate that you mean 'local time' at that location.
- zaxomi 3y ago
  And then they change the calendar. (It has already happened in several regions when changing from Julian to Gregorian calendar. You don't know what calendar will be used at that region in the future)
chaz6 3y ago
If you use coordinates, make sure to take into account continental drift. You could use a plate-local coordinate system (e.g. British National Grid for Great Britain) so you only need to take into account deformation. There is actually a good read on this at https://www.ordnancesurvey.co.uk/blog/is-britain-on-the-move https://www.ordnancesurvey.co.uk/blog/is-britain-on-the-move
- crooked-v 3y ago
  What about storing current geo coordinates and a timestamp of when they were recorded? I feel like that should be enough for a theoretical future system to adjust mapping for continental drift.

ilyt 3y ago

2030-07-01T18:00:00~Scotland/Glasgow ?

lmm 3y ago

> However, it is not unimaginable that in that time, Scotland could hold another referendum on independence and either join Central European Time, or create Scottish Standard Time. Or be in the middle of a political dispute, with different times being used depending which side one is on, like Xinjiang. So just knowing the place and local time isn't enough.

pizzafeelsright 3y ago

Suddenly, specifying noon on the third Tuesday on the second full moon after the summer equinox makes sense.

runarberg 3y ago
Solar noon or clock noon? What happens if the full moon is on Tuesday? Will that Tuesday count towards the third? Even if the full moon is at 23:59 (23:59 in which timezone)? Do you use solar equinox, or the Julian equinox, or the Gregorian equinox? I think you need to be more specific here.
- joquarky 3y ago
  I wonder what the downsides would be in a time model that is indicated by a normalized global value for the current longitude where the sun is at meridian.