3 ms·

Local time isn’t just a view it gets down into the model. You can’t effectively model “every Tuesday at 4pm until cancelled” as a series of timestamps because i

Local time isn’t just a view it gets down into the model. You can’t effectively model “every Tuesday at 4pm until cancelled” as a series of timestamps because it comes with an implied “…regardless of changes to daylight saving rules.” Heck you can’t even model “Oct 15 2030 at 2pm” as a timestamp for the same reason if it is an appointment involving two humans in the same tz. Somewhere you need to store the rule using local time concepts.

alphazard 1y ago
The input to the scheduler would be “every Tuesday at 4pm", and that would produce a schedule out to some time horizon. The schedule would be in terms of timestamps. When the criteria changes, the scheduler is rerun and a new tentative schedule is produced. > Somewhere you need to store the rule using local time concepts. The scheduling rules can be in terms of whatever you want and maybe that's local time or a timezone or soonest free block, but they are being used to solve for timestamps in the actual schedule. You run into problems if the scheduler output is in terms of any of those concepts.
taeric 1y ago
My favorite mistake is when people assume it is only daylight savings time that you need to consider. I could just be on vacation in a different place, but still want to keep the same schedule. And indeed, knowing that most places open around 9ish local time everywhere is very convenient. Another fun aspect of this topic is how people will tacitly jump around the definition of "day" being when the sun is up without confronting that that is, itself, not a given. And, worse, is completely thrown out if you try to abolish time zones.
theamk 1y ago
Agreed, but amazingly high number of people (ab)use the local time notation for things which don't need it, like timestamps of various events (login time, order time, etc..) It's worth repeating over and over: "Only use local time if the actual moment event happens depends on the timezone, like during future calendar entries. Every other time in the system should be a utc timestamp, converted to local time string at the very last presentation layer"

alphazard 1y ago

The input to the scheduler would be “every Tuesday at 4pm", and that would produce a schedule out to some time horizon. The schedule would be in terms of timestamps. When the criteria changes, the scheduler is rerun and a new tentative schedule is produced. > Somewhere you need to store the rule using local time concepts. The scheduling rules can be in terms of whatever you want and maybe that's local time or a timezone or soonest free block, but they are being used to solve for timestamps in the actual schedule. You run into problems if the scheduler output is in terms of any of those concepts.

taeric 1y ago

My favorite mistake is when people assume it is only daylight savings time that you need to consider. I could just be on vacation in a different place, but still want to keep the same schedule. And indeed, knowing that most places open around 9ish local time everywhere is very convenient. Another fun aspect of this topic is how people will tacitly jump around the definition of "day" being when the sun is up without confronting that that is, itself, not a given. And, worse, is completely thrown out if you try to abolish time zones.

theamk 1y ago

Agreed, but amazingly high number of people (ab)use the local time notation for things which don't need it, like timestamps of various events (login time, order time, etc..) It's worth repeating over and over: "Only use local time if the actual moment event happens depends on the timezone, like during future calendar entries. Every other time in the system should be a utc timestamp, converted to local time string at the very last presentation layer"