5 ms·

Then how do you express that something must happen at a date in the future at 4pm local time? If you use UTC based on today's expectation of daylight savings, t

by cm2187 3y ago

Then how do you express that something must happen at a date in the future at 4pm local time? If you use UTC based on today's expectation of daylight savings, they may have changed by the time this date happens.

amluto 3y ago
You start by figuring out what you’re even trying to do. For example, I read your comment three times, and I don’t know what you mean by “4 pm local time”. I don’t even have what I would consider to be a credible guess.
- jcranmer 3y ago
  Schedule an event to occur at 4pm every day, say in crontab.
  - amluto 3y ago
    Works great until you have an office in a different time zone. The whole concept of a computer belonging to a timezone works to some extent when that computer has a single human tenant, but it falls apart pretty quickly when the scope broadens.
    - jcranmer 3y ago
      If I'm scheduling a meeting, then yes, I am going to want to schedule the meeting using a specific time zone, which may or may not be my local time zone at that moment. But if I'm scheduling when I want my computer to reboot, I want that to be a fixed in time zone in my local time zone. And if I subsequently change my local time zone, I want it to remain at that time in the new local time zone, not the old one. Yes, local time zones don't always make sense. But that is a far cry from saying they never make sense!
      - amluto 3y ago
        I don’t know about you, but I have computers that aren’t in the same time zone I’m it. I probably want them to reboot at night where I am, not where they are. But yes, “reboot a laptop at 2am” is in the general category of alarm clock use cases, where a time (but not a date!) with a separately determined time zone makes sense. The OP mentioned LocalDateTime, which doesn’t make sense for this use case.
        falserum 3y ago
        Instant in history -> GMT+0/UTC Future shedule for humans to coordinate (contracts, meetings) -> ZonedDateTime Personal alarm that should be kept in sync with the sun (e.g. go to sleep) -> LocalDateTime What’s good example/purpose for OffsetDateTime?
        jcranmer 3y ago
        OffsetDateTime would be useful for a lot of historical records. For example, if I'm chronicling a WW2 battle in the Pacific, I need to know what the local times of the events were, but I don't necessarily care about knowing the DST rules. Additionally, most date/time serialization formats (e.g., RFC 822, ISO 3601) only allow you to specify up to OffsetDateTime and don't provide a full timezone reference like US/Eastern.
- zodiac 3y ago
  Something like "schedule a reminder to stop using the computer at 10pm so I can sleep by 11pm"? Since I want to sleep at 11pm local time every day
  - amluto 3y ago
    This is about the only use case for local time that makes sense to me. But this is a UI issue, and it seems to me that that should be something that comes from a UI library or framework, not from libc and or /etc or environment variables. (I’m using “UI” broadly. A user session on a UNIXy system could have an associated timezone, although such a design should allow changing the timezone without logging on and off. And this “10pm local” thing is quite different from an ordinary zoned time in that “10pm local in 10 days” does not correspond to an actual known UTC time because the local time zone may change.)
- falserum 3y ago
  1. Contract says that goods must be delivered at 4pm. 2. Government suddenly changes the law and moves the offset of whole country. 3. Contract is still valid, goods have to be delivered still at 4pm, but with new offset (so at different utc time). (I guess timezoned time would still be better than local time, but UTC would not work here)
  - mharig 3y ago
    1. Contract says that goods must be delivered at 4pm UTC Problem solved, unless the government changes the law too little before 4pm UTC. But handling this case in software is impractical.
  - amluto 3y ago
    > (I guess timezoned time would still be better than local time, but UTC would not work here) Exactly.
- MereInterest 3y ago
  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."
- joshribakoff 3y ago
  > don’t know what you mean by “4 pm local time” It means “whenever it is 4pm wherever you are”. As in, i want my alarm to go off at 4pm everyday regardless of whether i am traveling. Python calls it a “naive” time, it has no timezone or offset. Its just a data structure that says “4pm” rather than “4pm eastern time” An example ive used is when a user had to specify schedules for a digital menu board system. When the user says breakfast ends at 10am, that means wherever the digital menu board is located, not “10am where i was when i set the schedule”. It also doesn’t mean “end breakfast an hour early/late when daylight savings occurs” It makes sense in any context where you need to do something at a certain time each day, and you specifically don’t mean “do this thing exactly every 24hrs”
  - amluto 3y ago
    > As in, i want my alarm to go off at 4pm everyday regardless of whether i am traveling. I think this may be the exception that proves the rule. Sure, this is a valid, if specialized, semantic use case. But you only barely need a LocalDateTime type for this. If you stick that 4pm into a local database, you want to make sure that everything, including the database, knows you’re storing hours, minutes, and seconds relative to an unspecified “local time”. So IMO this is more of an UnspecifiedZoneTime than a LocalDateTime. (Also, it has no date portion.) It makes no sense to compare it to a UTC or other date+time.
    - coldtea 3y ago
      >So IMO this is more of an UnspecifiedZoneTime than a LocalDateTime. (Also, it has no date portion. It very well could also have a date portion. E.g. "I want this alarm/cleanup/whatever to happen on 9am on the 1st Monday of each month" based on the timezone the user happens to be at that time - i.e. not tied to any specific timezone.
      - amluto 3y ago
        That’s still a different thing: it’s a recurring event, which is an almost entirely separate can of worms from a datetime. And a recurrence library probably wants to avoid libc-style “localtime” here — plumbing the concept of users in places to it seems awkward. A genuinely naive time may be better — the interface could be “calculate the next recurrence of this recurring event in this timezone,” not “here’s a recurring event with associated ‘local’ time — calculate the next occurrence given my /etc/localtime and TZ environment variable”.

by cm2187 3y ago

amluto 3y ago

You start by figuring out what you’re even trying to do. For example, I read your comment three times, and I don’t know what you mean by “4 pm local time”. I don’t even have what I would consider to be a credible guess.

jcranmer 3y ago
Schedule an event to occur at 4pm every day, say in crontab.
- amluto 3y ago
  Works great until you have an office in a different time zone. The whole concept of a computer belonging to a timezone works to some extent when that computer has a single human tenant, but it falls apart pretty quickly when the scope broadens.
  - jcranmer 3y ago
    If I'm scheduling a meeting, then yes, I am going to want to schedule the meeting using a specific time zone, which may or may not be my local time zone at that moment. But if I'm scheduling when I want my computer to reboot, I want that to be a fixed in time zone in my local time zone. And if I subsequently change my local time zone, I want it to remain at that time in the new local time zone, not the old one. Yes, local time zones don't always make sense. But that is a far cry from saying they never make sense!
    - amluto 3y ago
      I don’t know about you, but I have computers that aren’t in the same time zone I’m it. I probably want them to reboot at night where I am, not where they are. But yes, “reboot a laptop at 2am” is in the general category of alarm clock use cases, where a time (but not a date!) with a separately determined time zone makes sense. The OP mentioned LocalDateTime, which doesn’t make sense for this use case.
      - falserum 3y ago
        Instant in history -> GMT+0/UTC Future shedule for humans to coordinate (contracts, meetings) -> ZonedDateTime Personal alarm that should be kept in sync with the sun (e.g. go to sleep) -> LocalDateTime What’s good example/purpose for OffsetDateTime?
        jcranmer 3y ago
        OffsetDateTime would be useful for a lot of historical records. For example, if I'm chronicling a WW2 battle in the Pacific, I need to know what the local times of the events were, but I don't necessarily care about knowing the DST rules. Additionally, most date/time serialization formats (e.g., RFC 822, ISO 3601) only allow you to specify up to OffsetDateTime and don't provide a full timezone reference like US/Eastern.
zodiac 3y ago
Something like "schedule a reminder to stop using the computer at 10pm so I can sleep by 11pm"? Since I want to sleep at 11pm local time every day
- amluto 3y ago
  This is about the only use case for local time that makes sense to me. But this is a UI issue, and it seems to me that that should be something that comes from a UI library or framework, not from libc and or /etc or environment variables. (I’m using “UI” broadly. A user session on a UNIXy system could have an associated timezone, although such a design should allow changing the timezone without logging on and off. And this “10pm local” thing is quite different from an ordinary zoned time in that “10pm local in 10 days” does not correspond to an actual known UTC time because the local time zone may change.)
falserum 3y ago
1. Contract says that goods must be delivered at 4pm. 2. Government suddenly changes the law and moves the offset of whole country. 3. Contract is still valid, goods have to be delivered still at 4pm, but with new offset (so at different utc time). (I guess timezoned time would still be better than local time, but UTC would not work here)
- mharig 3y ago
  1. Contract says that goods must be delivered at 4pm UTC Problem solved, unless the government changes the law too little before 4pm UTC. But handling this case in software is impractical.
- amluto 3y ago
  > (I guess timezoned time would still be better than local time, but UTC would not work here) Exactly.
MereInterest 3y ago
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."
joshribakoff 3y ago
> don’t know what you mean by “4 pm local time” It means “whenever it is 4pm wherever you are”. As in, i want my alarm to go off at 4pm everyday regardless of whether i am traveling. Python calls it a “naive” time, it has no timezone or offset. Its just a data structure that says “4pm” rather than “4pm eastern time” An example ive used is when a user had to specify schedules for a digital menu board system. When the user says breakfast ends at 10am, that means wherever the digital menu board is located, not “10am where i was when i set the schedule”. It also doesn’t mean “end breakfast an hour early/late when daylight savings occurs” It makes sense in any context where you need to do something at a certain time each day, and you specifically don’t mean “do this thing exactly every 24hrs”
- amluto 3y ago
  > As in, i want my alarm to go off at 4pm everyday regardless of whether i am traveling. I think this may be the exception that proves the rule. Sure, this is a valid, if specialized, semantic use case. But you only barely need a LocalDateTime type for this. If you stick that 4pm into a local database, you want to make sure that everything, including the database, knows you’re storing hours, minutes, and seconds relative to an unspecified “local time”. So IMO this is more of an UnspecifiedZoneTime than a LocalDateTime. (Also, it has no date portion.) It makes no sense to compare it to a UTC or other date+time.
  - coldtea 3y ago
    >So IMO this is more of an UnspecifiedZoneTime than a LocalDateTime. (Also, it has no date portion. It very well could also have a date portion. E.g. "I want this alarm/cleanup/whatever to happen on 9am on the 1st Monday of each month" based on the timezone the user happens to be at that time - i.e. not tied to any specific timezone.
    - amluto 3y ago
      That’s still a different thing: it’s a recurring event, which is an almost entirely separate can of worms from a datetime. And a recurrence library probably wants to avoid libc-style “localtime” here — plumbing the concept of users in places to it seems awkward. A genuinely naive time may be better — the interface could be “calculate the next recurrence of this recurring event in this timezone,” not “here’s a recurring event with associated ‘local’ time — calculate the next occurrence given my /etc/localtime and TZ environment variable”.