4 ms·

> 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

> 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”.

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”.