-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ISO8601 Date String options in Logged Data #116
Comments
Active discussion in the 16 August 2023 meeting. Item is still open. Questions to be resolved:
|
All three are fine but maybe be explicit that it can be ONLY one of the three variants. Time on implements, tractors, and monitors are a stinker. No reason to be complex when good parsers exist to handle all three of those. |
I understand @knelson-farmbeltnorth points above and our conversation in ADAPT Standard meeting a few weeks ago to suggest that when a time instance is recorded, one of two conditions is true:
Note that this is not the same thing as knowing/not knowing the time zone the clock system is in when it reported date/time information. One cannot assume that because a time is indicated in JST that the related event occurred in Japan. One could harvest corn in Iowa recording time in JST, which from an ISO 8601 perspective is just fine (albeit strange). For condition 1, I highly recommend requiring that time be expressed in UTC. If the local time zone matters, record it as a separate piece of information. For developers of robust systems UTC will simplify the following scenarios (and no doubt myriad others):
While stating times with UTC offsets would computationally work just fine, it would result in some apparently odd-looking date/times to those who don't have the finer points of ISO 8601 in mind. Put the date/time-semantics burden on data producers rather than data consumers. For condition 2, I guess some date/time information is better than none, but there is quite a range of ambiguity. Furthermore, in my opinion, any date/time system that knows the date/time but doesn't know the time zone or is incapable of expressing date/time in UTC is a suspect system. Based on my earlier comments, you won't be surprised that I highly recommend not relying on time zones expressed in date/time information to indicate the time zone in which an operation occurred (or more generally, anything at all about geography). As I write this, it is 2023-09-20T23:45+13:00. What time zone am I in? |
Answer: US Eastern Daylight Time The point: It would be perilous to rely on the UTC offset to deduce anything about geography. I would grant that inferences in social circumstances are common and often reasonable, but occasionally result in frustration. |
Agreement in 20 September 2023 meeting that we require timestamps in the ISO8601 "Z" format (UTC without a defined timezone offset). If a data producer has only local time without knowledge of the timezone other than some record of where the data physically is, they must use that to convert to Z time. Otherwise that exercise falls to the data consumer and violates the ADAPT Standard principle that the data producer makes the effort to "standardize" the data. |
We will be logging timestamps in ISO8601 format in the Logged Data. There is some disagreement on what should be allowed. Using examples from https://www.w3.org/TR/NOTE-datetime, there are 3 possible representations
1994-11-05T08:15:30 (local time when time zone offset is unknown)
1994-11-05T08:15:30-05:00 (local time + time zone offset)
1994-11-05T13:15:30Z (UTC without a reference to time zone)
Ideally, all times would be in the 2nd example. However, there are cases where the logging device does not have a record of its timezone. E.g.s, UTC dates in GNSS data, a monitor set to local time without knowledge of its timezone. ISO 11783 allows all of the above variations except in the case of the primary timestamp on the spatial records which must be in local time.
The text was updated successfully, but these errors were encountered: