4 ms·

> The issue is, what do you mean? It would simply mean the time which is intended. It’s true that the instant isn’t known until it happens (or however much lee

by klabb3 3y ago

> The issue is, what do you mean? It would simply mean the time which is intended. It’s true that the instant isn’t known until it happens (or however much leeway precedes a TZ change). It’s generally always better to record intent, than to be smart and translate inputs to something else. To map to a specific instant in UTC time, you use the string plus a db. The db can change in the future, and that’s ok. You simply update in the presentation layer in case you have any “2h left” strings or calendar entries. Note you should NOT store the mapped instance in a db before the event has occurred (and even then it’s unnecessary since it’s fixed). I really don’t like the “inconsistent” mutable property and agree with parent that offset should not be part of the format. That would make it extremely easy to overlook or misuse. Perhaps I’m missing something?

mjevans 3y ago
I agree on not including the offset. However I'm saying that the solution should be radically different and much more user focused. There is a difference between a description of when to capture a moment (which should favor the way the normal person describes moments) and an absolute moment event.
efitz 3y ago
> Perhaps I’m missing something? Yes, you’re missing something - geography. “Local time” doesn’t include a frame of reference. If you want to have a meaningful representation of local time you need syntax to specify where, probably Lat/Long. Then, periodically, the computer can look up the lat/long to see what the rules are there for time, and compare vs the target time. But even THAT doesn’t solve the problem, because you probably don’t want the computer in a tight loop of looking up location rules for time and checking time. But if you do it periodically then there is a nonzero chance that you will miss the event because the rules changed since the last check and the current check happened after the event. And you can’t just use the city names for time zones (e.g. “Europe/London”) because only a very small number of places have such names, and because they really refer to a combination of time zone and DST rules, not to a city, they just choose representative cities. Finally, ISO 8601 does support durations, which RFC 3339 does not, so ISO seems more useful in that regard, but durations are not relative to any epoch.

by klabb3 3y ago

mjevans 3y ago

I agree on not including the offset. However I'm saying that the solution should be radically different and much more user focused. There is a difference between a description of when to capture a moment (which should favor the way the normal person describes moments) and an absolute moment event.

efitz 3y ago

> Perhaps I’m missing something? Yes, you’re missing something - geography. “Local time” doesn’t include a frame of reference. If you want to have a meaningful representation of local time you need syntax to specify where, probably Lat/Long. Then, periodically, the computer can look up the lat/long to see what the rules are there for time, and compare vs the target time. But even THAT doesn’t solve the problem, because you probably don’t want the computer in a tight loop of looking up location rules for time and checking time. But if you do it periodically then there is a nonzero chance that you will miss the event because the rules changed since the last check and the current check happened after the event. And you can’t just use the city names for time zones (e.g. “Europe/London”) because only a very small number of places have such names, and because they really refer to a combination of time zone and DST rules, not to a city, they just choose representative cities. Finally, ISO 8601 does support durations, which RFC 3339 does not, so ISO seems more useful in that regard, but durations are not relative to any epoch.