4 ms·

You and I would like to meet at a coffee shop, on a specific date about six months from now, when the clock on the wall of the coffee shop reads "4:00 PM". * T

You and I would like to meet at a coffee shop, on a specific date about six months from now, when the clock on the wall of the coffee shop reads "4:00 PM". * The coffee shop may not be located within UTC+00:00. If you show up at UTC time 16:00+00:00, I won't be there. * The coffee shop may not be located in your current time zone. If you show up when it is "4:00 PM" in your local time zone, I won't be there. * The coffee shop may be located somewhere that follows Daylight Saving Time. If you show up when it is "4:00 PM" in the current UTC offset of the coffee shop, I won't be there. * The coffee shop may currently be located somewhere that follows Daylight Saving Time, but the legislature stops following Daylight Saving Time between now and our meeting. If you show up when it is "4:00 PM" according to the predicted UTC offset of the coffee shop for the day of the meeting, rather than the actual UTC offset of the coffee shop for the day of the meeting, I won't be there. Saying "local time" implies all of the above. It means that something is being specified according to the local convention of timekeeping.

amluto 3y ago
> Saying "local time" implies all of the above. It means that something is being specified according to the local convention of timekeeping. No, it really doesn’t. Saying “4pm at the coffee shop” means that, and this is a big distinction. If I’m in a different time zone two days before the meeting, looking at my calendar, I sure hope my calendar understands the difference. If I move my entire home outside the timezone, the appointment doesn’t magically shift an hour as a result. And any decent time library can handle this just fine as long as you don’t use “local” time. Just specify the actual timezone!
- lijok 3y ago
  Unfortunately timezones have the nasty ability to change. See: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/ https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...
  - Hackbraten 3y ago
    That's why they wrote "state the actual timezone" and not "state the actual UTC offset." Actual timezone would mean "2025-01-01 16:00:00 Europe/Berlin," not just "2025-01-01 16:00:00 +01:00."
    - lijok 3y ago
      Even those change
      - Hackbraten 3y ago
        I agree. The city where the cafe is located might be annexed or usurped by another country, and have another timezone imposed on it. Handling that kind of change would be beyond impractical though?
        lijok 3y ago
        Good question. I wonder what impact timezone wise the annexation of Crimea had on hypergiants like FAANG. I can imagine some weirdness when rerunning say historical domain events to hydrate a new service. Wonder if they have libraries to handle such edgecases
- MereInterest 3y ago
  > No, it really doesn’t. Saying “4pm at the coffee shop” means that, and this is a big distinction. Some words and phrases, such as "4 pm local time", require some of their semantic meaning to be inferred from context. This doesn't mean that they are meaningless. It means that the relevant context must be provided in order to interpret the phrase. If you and I have been scheduling the coffee shop meetup, then the phrases "4pm", "4pm local time", and "4pm as measured by the applicable standards in the area of the coffee shop on the day of the meeting" are all equivalent. > Just specify the actual timezone! This is the problem that I pointed out. The appropriate context for "4pm local time" is "at the coffee shop". However, most calendar programs will only let you provide context such as "Eastern Standard Time". This is the wrong context altogether, and choosing it assumes that the area will have extended the duration of DST between time of scheduling and time of meeting.
  - amluto 3y ago
    > Some words and phrases, such as "4 pm local time", require some of their semantic meaning to be inferred from context. This doesn't mean that they are meaningless. It means that the relevant context must be provided in order to interpret the phrase. This is not what the proposed LocalDateTime would do. This is a “naive” time, and those are only really useful for calendar math or when you want to apply a concrete timezone.
lelandbatey 3y ago
Nah, you need a location; it's right there in the name "local" which implies time at a place. Saying "local time" alone doesn't always give sufficient detail in your example, because you want the device to be able to change it's location (its timekeeping context) while maintaining awareness of the difference between the device's local time and the local time of the thing you've recorded. "Local time" is basically never "good enough", actually. At a minimum, a time as you've described should include: - a location where you're tracking the local time - the destination local time at that location, from which you can derive most of the timekeeping context (time zone), usually - the current time of the thing doing the computation, in order to accurately compare device to destination time You then use those to get a UTC time that you can use to do things like a countdown. Or you can just make assumptions about those things and accept they'll be wrong; that's allowed but it's not usually what users want given we KNOW how to give them what they want.

amluto 3y ago

> Saying "local time" implies all of the above. It means that something is being specified according to the local convention of timekeeping. No, it really doesn’t. Saying “4pm at the coffee shop” means that, and this is a big distinction. If I’m in a different time zone two days before the meeting, looking at my calendar, I sure hope my calendar understands the difference. If I move my entire home outside the timezone, the appointment doesn’t magically shift an hour as a result. And any decent time library can handle this just fine as long as you don’t use “local” time. Just specify the actual timezone!

lijok 3y ago
Unfortunately timezones have the nasty ability to change. See: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/ https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...
- Hackbraten 3y ago
  That's why they wrote "state the actual timezone" and not "state the actual UTC offset." Actual timezone would mean "2025-01-01 16:00:00 Europe/Berlin," not just "2025-01-01 16:00:00 +01:00."
  - lijok 3y ago
    Even those change
    - Hackbraten 3y ago
      I agree. The city where the cafe is located might be annexed or usurped by another country, and have another timezone imposed on it. Handling that kind of change would be beyond impractical though?
      - lijok 3y ago
        Good question. I wonder what impact timezone wise the annexation of Crimea had on hypergiants like FAANG. I can imagine some weirdness when rerunning say historical domain events to hydrate a new service. Wonder if they have libraries to handle such edgecases
MereInterest 3y ago
> No, it really doesn’t. Saying “4pm at the coffee shop” means that, and this is a big distinction. Some words and phrases, such as "4 pm local time", require some of their semantic meaning to be inferred from context. This doesn't mean that they are meaningless. It means that the relevant context must be provided in order to interpret the phrase. If you and I have been scheduling the coffee shop meetup, then the phrases "4pm", "4pm local time", and "4pm as measured by the applicable standards in the area of the coffee shop on the day of the meeting" are all equivalent. > Just specify the actual timezone! This is the problem that I pointed out. The appropriate context for "4pm local time" is "at the coffee shop". However, most calendar programs will only let you provide context such as "Eastern Standard Time". This is the wrong context altogether, and choosing it assumes that the area will have extended the duration of DST between time of scheduling and time of meeting.
- amluto 3y ago
  > Some words and phrases, such as "4 pm local time", require some of their semantic meaning to be inferred from context. This doesn't mean that they are meaningless. It means that the relevant context must be provided in order to interpret the phrase. This is not what the proposed LocalDateTime would do. This is a “naive” time, and those are only really useful for calendar math or when you want to apply a concrete timezone.

lelandbatey 3y ago

Nah, you need a location; it's right there in the name "local" which implies time at a place. Saying "local time" alone doesn't always give sufficient detail in your example, because you want the device to be able to change it's location (its timekeeping context) while maintaining awareness of the difference between the device's local time and the local time of the thing you've recorded. "Local time" is basically never "good enough", actually. At a minimum, a time as you've described should include: - a location where you're tracking the local time - the destination local time at that location, from which you can derive most of the timekeeping context (time zone), usually - the current time of the thing doing the computation, in order to accurately compare device to destination time You then use those to get a UTC time that you can use to do things like a countdown. Or you can just make assumptions about those things and accept they'll be wrong; that's allowed but it's not usually what users want given we KNOW how to give them what they want.