←back to thread

189 points rmason | 1 comments | | HN request time: 0.27s | source
Show context
alphazard ◴[] No.44377042[source]
There's nothing special about time. These sorts of problems show up whenever there are a few overloaded terms being used to model a larger amount of concepts.

Confusion about special and general relativity accounts for almost none of the problems that programmers encounter in practice. If that's your use case, then fine, time is special and tricky.

The most common issue is a failure to separate models vs. view concepts. e.g. timestamps are a model, but local time, day of the week, leap seconds are all view concepts. The second most common issue is thinking that UTC is suitable to use as a model, instead of the much more reasonable TAI64. After that it's probably the difference between scheduling requests vs. logging what happened. "The meeting is scheduled next Wednesday at 9am local time" vs. "the meeting happened in this time span". One is a fact about the past, and the other is just scheduling criteria. It could also be something complicated like "every other Wednesday", or every "Wednesday on an even number day of the month". Or "we can work on this task once these 2 machines are available", "this process will run in 2 time slots from now", etc.

https://cr.yp.to/libtai/tai64.html

replies(2): >>44377182 #>>44378566 #
eduction ◴[] No.44377182[source]
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.

replies(3): >>44377902 #>>44377962 #>>44378603 #
1. theamk ◴[] No.44378603[source]
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"