ISO8601 Date String options in Logged Data

[knelson-farmbeltnorth]

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.

[knelson-farmbeltnorth]

Active discussion in the 16 August 2023 meeting. Item is still open. Questions to be resolved:

1. Do we need to limit to one of the above formats?
2. If we disallow local time without an offset, are we preventing ISO11783-10 data from being converted into the ADAPT standard without the data producer taking the step to derive the timezone from date and location?
3. Pending the answer to the above two items, is reasonable compromise that we require all TimeRecords use the Z format and place an optional but recommended time zone offset property somewhere else in the model?

[zwing99]

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.

[jim-wilson-kt]

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:

1. The date/time complete with time zone information is known or can be determined.
2. The date/time complete with time zone information is not known and cannot be determined.

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):

• Field operations that cross time zones (even the case where at an instant one spray nozzle is in one time zone while another is in another time zone)
• Field operations occurring in the hours around daylight saving time / summer time adjustments

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?

[jim-wilson-kt]

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.

[knelson-farmbeltnorth]

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.