8 ms·

Well is it a local time or not. If it is a local time where is it a local time? You need a timezone as well.

tsimionescu 1y ago
A local time is not tied to a timezone. When I set my wake up alarm at 8:30 every day, it should stay at 8:30 regardless of the current timezone. If I travel to the USA, my phone shouldn't start waking me up at 22:30.
- bsaul 1y ago
  The datetime mentionned in parent post had both a date and a time component, which has the meaning of a "point in time". Not just a "time". Point in time needs location information to guess the timezone, otherwise you simply can't make anything out of it. Your definition would have been just storing "hh:mm:ss".
  - ivan_gammel 1y ago
    You are right that LocalDateTime requires location, but it is not part of the data type and data format. It’s just date and time without timezone and location is stored separately.
    - fauigerzigerk 1y ago
      >You are right that LocalDateTime requires location No. If I set a reminder for a particular date and time in the future, I want it to go off at that local date and time wherever I may be. The location cannot be part of the data type because "local" is sometimes relative to movable objects.
      - bsaul 1y ago
        good point, never thought of that.
      - ivan_gammel 1y ago
        I don’t understand your objection. Local date and time is always bound to a local timezone, it‘s just implicit. Even in case of movable objects, the exact moment of time is defined by the watch aboard that object. You are on a ship and you wake up at 7am to get ready for breakfast? The exact moment of time when it happens is in the local time zone. The bar around the corner opens at 4pm? It’s in the local timezone, no matter how it changes. And „local“ means the timezone is defined by location, a ship, a city etc, so to calculate the exact moment of time you do location timezone lookup. Your phone does that automatically, picking up the timezone from cell tower and adjusting your local clock, so that alarm set at 7 (which is LocalTime) would work correctly.
        1718627440 1y ago
        > Local date and time is always bound to a local timezone, it‘s just implicit. It does not that's the key of this argument. Here local means "on this device", whatever dumb time this has.
        ivan_gammel 1y ago
        Do you understand what „implicit“ means?
        1718627440 1y ago
        Yes, but it's still not bound to a timezone, unless you define "all the timezones this device goes through" as a timezone.
  - tsimionescu 1y ago
    That's a good point, I hadn't thought of that part. Local times can make sense, but datetimes really should always have a location timezone associated.
    - yencabulator 1y ago
      I have an application that receives a feed of availabilities, like the fact that you could reserve an item or service on 2025-10-20 at 13:00, it is currently available. The feed is global and the location of the business is a human-input address with potential errors, sometimes but not always has GPS coordinates (that may also be incorrect), and often where the actual service will happen is not the same as the location of the retail business. Yeah. It's just whatever 1 in the afternoon means in the local time, at the time of the reservation. I don't know what the timezone is. But they definitely have dates!
- shmerl 1y ago
  Local time is irrelevant when you present that time to someone else external. How would they know what your local timezone is? This presentation tells them nothing about it. So it's good for local use, but inadequate for any use that's not tied to your local environment. Alarms and etc. are already using it, so it's not about that use case.
fauigerzigerk 1y ago
No, I think it's very important to understand that local times in the future do not identify a point in time and that local times are not necessarily tied to any particular location. If I set my alarm clock to 7am, I want it to always wake me at 7am local time regardless of where I happen to be on that day. If I make an appointment for 7 Sep 2026 at 3pm I'm going to turn up at whatever time counts as 3pm on that date. The government might scrap DST, so the exact point in time is currently unknown. Many uses of local time cannot be expressed correctly if you are forced to specify a timezone.
- bakje 1y ago
  This is true when using a UTC offset as it has any potential DST already applied, so it can’t adapt to changes like that. But if you say I have an appointment at 2026-09-07 15:00:00 in the timezone America/New_York I think that also accounts for future rule changes of that timezone. I’m no expert on this matter but I believe that’s similar to how the new JS temporal API handles such things
  - bloak 1y ago
    Unless New York gets split into two, Berlin-style, and the parts have different time zones.
    - mcny 1y ago
      Should it ring twice if you go across the border one way? Should it not ring if you go across the border the other way?
      - oasisaimlessly 1y ago
        Yes? Same could be said right now for setting an alarm during the hour skipped/repeated by a DST transition.
  - fauigerzigerk 1y ago
    If the definition of timezone names can change, then the combination of a future datetime and a timezone name does not identify a point in time. Also, what if I don't know yet where I will be and I want to set a reminder for a particular date and time?
macote 1y ago
I think 'local' in this context could also simply mean 'wall', as in wall clock time. When my friend asks me the date and time, I don't have to bother with time zones. This type of date/time is also very useful to store in a computer.
- pasc1878 1y ago
  Yes but you agree on the same time zone. If you are on a phone call when you are in London and the other end is in New York - what is the time?
  - defrost 1y ago
    Now. Having had decades of this in geophysical exploration, the time is now AND (where relevant) it's the current UTC Zulu time AND it's both local times. Any data collected is logged against a UTC sync for start of recording (and continues with lapsed time AND logging raw GPS times .. which sorts out leap second issues). Any discussion re: start of next data collection is relative to the local time at the field end, the planes et al are often bound by daylight - so field operation local dawn and sunset are relevant. Any discussion re: software changes | hardware support is relevant to the local time at the home office end as that'll rest on when the office staff or aircraft mechanics come in or free up. For ease of communication many such discussions are along the lines of "we'll ring back in four hours and ...". That's a NOW relative epoch.

A local time is not tied to a timezone. When I set my wake up alarm at 8:30 every day, it should stay at 8:30 regardless of the current timezone. If I travel to the USA, my phone shouldn't start waking me up at 22:30.

bsaul 1y ago
The datetime mentionned in parent post had both a date and a time component, which has the meaning of a "point in time". Not just a "time". Point in time needs location information to guess the timezone, otherwise you simply can't make anything out of it. Your definition would have been just storing "hh:mm:ss".
- ivan_gammel 1y ago
  You are right that LocalDateTime requires location, but it is not part of the data type and data format. It’s just date and time without timezone and location is stored separately.
  - fauigerzigerk 1y ago
    >You are right that LocalDateTime requires location No. If I set a reminder for a particular date and time in the future, I want it to go off at that local date and time wherever I may be. The location cannot be part of the data type because "local" is sometimes relative to movable objects.
    - bsaul 1y ago
      good point, never thought of that.
    - ivan_gammel 1y ago
      I don’t understand your objection. Local date and time is always bound to a local timezone, it‘s just implicit. Even in case of movable objects, the exact moment of time is defined by the watch aboard that object. You are on a ship and you wake up at 7am to get ready for breakfast? The exact moment of time when it happens is in the local time zone. The bar around the corner opens at 4pm? It’s in the local timezone, no matter how it changes. And „local“ means the timezone is defined by location, a ship, a city etc, so to calculate the exact moment of time you do location timezone lookup. Your phone does that automatically, picking up the timezone from cell tower and adjusting your local clock, so that alarm set at 7 (which is LocalTime) would work correctly.
      - 1718627440 1y ago
        > Local date and time is always bound to a local timezone, it‘s just implicit. It does not that's the key of this argument. Here local means "on this device", whatever dumb time this has.
        ivan_gammel 1y ago
        Do you understand what „implicit“ means?
        1718627440 1y ago
        Yes, but it's still not bound to a timezone, unless you define "all the timezones this device goes through" as a timezone.
- tsimionescu 1y ago
  That's a good point, I hadn't thought of that part. Local times can make sense, but datetimes really should always have a location timezone associated.
  - yencabulator 1y ago
    I have an application that receives a feed of availabilities, like the fact that you could reserve an item or service on 2025-10-20 at 13:00, it is currently available. The feed is global and the location of the business is a human-input address with potential errors, sometimes but not always has GPS coordinates (that may also be incorrect), and often where the actual service will happen is not the same as the location of the retail business. Yeah. It's just whatever 1 in the afternoon means in the local time, at the time of the reservation. I don't know what the timezone is. But they definitely have dates!
shmerl 1y ago
Local time is irrelevant when you present that time to someone else external. How would they know what your local timezone is? This presentation tells them nothing about it. So it's good for local use, but inadequate for any use that's not tied to your local environment. Alarms and etc. are already using it, so it's not about that use case.

fauigerzigerk 1y ago

No, I think it's very important to understand that local times in the future do not identify a point in time and that local times are not necessarily tied to any particular location. If I set my alarm clock to 7am, I want it to always wake me at 7am local time regardless of where I happen to be on that day. If I make an appointment for 7 Sep 2026 at 3pm I'm going to turn up at whatever time counts as 3pm on that date. The government might scrap DST, so the exact point in time is currently unknown. Many uses of local time cannot be expressed correctly if you are forced to specify a timezone.

bakje 1y ago
This is true when using a UTC offset as it has any potential DST already applied, so it can’t adapt to changes like that. But if you say I have an appointment at 2026-09-07 15:00:00 in the timezone America/New_York I think that also accounts for future rule changes of that timezone. I’m no expert on this matter but I believe that’s similar to how the new JS temporal API handles such things
- bloak 1y ago
  Unless New York gets split into two, Berlin-style, and the parts have different time zones.
  - mcny 1y ago
    Should it ring twice if you go across the border one way? Should it not ring if you go across the border the other way?
    - oasisaimlessly 1y ago
      Yes? Same could be said right now for setting an alarm during the hour skipped/repeated by a DST transition.
- fauigerzigerk 1y ago
  If the definition of timezone names can change, then the combination of a future datetime and a timezone name does not identify a point in time. Also, what if I don't know yet where I will be and I want to set a reminder for a particular date and time?

macote 1y ago

I think 'local' in this context could also simply mean 'wall', as in wall clock time. When my friend asks me the date and time, I don't have to bother with time zones. This type of date/time is also very useful to store in a computer.

pasc1878 1y ago
Yes but you agree on the same time zone. If you are on a phone call when you are in London and the other end is in New York - what is the time?
- defrost 1y ago
  Now. Having had decades of this in geophysical exploration, the time is now AND (where relevant) it's the current UTC Zulu time AND it's both local times. Any data collected is logged against a UTC sync for start of recording (and continues with lapsed time AND logging raw GPS times .. which sorts out leap second issues). Any discussion re: start of next data collection is relative to the local time at the field end, the planes et al are often bound by daylight - so field operation local dawn and sunset are relevant. Any discussion re: software changes | hardware support is relevant to the local time at the home office end as that'll rest on when the office staff or aircraft mechanics come in or free up. For ease of communication many such discussions are along the lines of "we'll ring back in four hours and ...". That's a NOW relative epoch.