3 ms·

Maybe ` 2030-07-01T18:00:00[!Local] ` Where no offset and the !Local tell the app to use OOB defined location?

ilyt 3y ago
maybe ~ ? 2030-07-01T18:00:00~BTC 2030-07-01T18:00:00~CEST 2030-07-01T18:00:00~Local 2030-07-01T18:00:00~Europe/Warsaw to signify it is not a constant point in time but timezone-at-the-time dependent.
- mjevans 3y ago
  The issue is, what do you mean? This time description in the indicated timezone, at the instant it is correct? (Ignore updates, I mean the time I said. E.G. The doors open at 8am every day.) An indicated end of a duration, such as the period of time a mass of decaying radio-isotopes are valid for the sensor during? (Offhand, no consumer equipment comes to mind, but for an extremely sensitive calibrated sample it could matter and this is a contrived example.) Exact moment in monotonic time. (What about stretchy leap seconds too?) Something between the two extremes? Most humans probably want a default of something like... "Looser more common use time unless I get more specific." So if a TZ is included, it isn't a fixed moment, but whatever specifier is the valid moment as that moment passes. Convert it to an absolute monotonic value at that time to record the event and not just the specification of when to capture the event's passing. E.G. Unix time Epoch was 1970-01-01 00:00:00~Z with an absolute reference value of 0s DATE RoundedHour~US.EST => Actually is EDT but most people don't use that notation, and congress changed when DST happens yet again without abolishing it too, and this happened last year before the change but the event did run from Noon to 9PM with these event moment second values...
  - 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.
zaxomi 3y ago
Except you don't even know if they in the future uses the same calendar.
- trifurcate 3y ago
  We don't even know if the future can read or write in our commonly used alphabets.
  - euroderf 3y ago
    Or maybe even time reverses course and runs backwards. See: PK Dick, Counter-Clock World, 1967.

ilyt 3y ago

maybe ~ ? 2030-07-01T18:00:00~BTC 2030-07-01T18:00:00~CEST 2030-07-01T18:00:00~Local 2030-07-01T18:00:00~Europe/Warsaw to signify it is not a constant point in time but timezone-at-the-time dependent.

mjevans 3y ago
The issue is, what do you mean? This time description in the indicated timezone, at the instant it is correct? (Ignore updates, I mean the time I said. E.G. The doors open at 8am every day.) An indicated end of a duration, such as the period of time a mass of decaying radio-isotopes are valid for the sensor during? (Offhand, no consumer equipment comes to mind, but for an extremely sensitive calibrated sample it could matter and this is a contrived example.) Exact moment in monotonic time. (What about stretchy leap seconds too?) Something between the two extremes? Most humans probably want a default of something like... "Looser more common use time unless I get more specific." So if a TZ is included, it isn't a fixed moment, but whatever specifier is the valid moment as that moment passes. Convert it to an absolute monotonic value at that time to record the event and not just the specification of when to capture the event's passing. E.G. Unix time Epoch was 1970-01-01 00:00:00~Z with an absolute reference value of 0s DATE RoundedHour~US.EST => Actually is EDT but most people don't use that notation, and congress changed when DST happens yet again without abolishing it too, and this happened last year before the change but the event did run from Noon to 9PM with these event moment second values...
- 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.

zaxomi 3y ago

Except you don't even know if they in the future uses the same calendar.

trifurcate 3y ago
We don't even know if the future can read or write in our commonly used alphabets.
- euroderf 3y ago
  Or maybe even time reverses course and runs backwards. See: PK Dick, Counter-Clock World, 1967.