Clarify timestamp with -00 offset

[bscSCORM]

A Timestamp MUST be formatted according to ISO 8601.
A Timestamp SHOULD* be expressed using the format described in RFC 3339, which is a profile of ISO 8601.

ISO 8601 forbids an offset of -00, RFC 3339 treats it as a valid representation of Z (UTC)

An offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00". However, it is not permitted to state it numerically with a negative sign, as "−00:00", "−0000", or "−00". The section dictating sign usage (section 3.4.2 in the 2004 edition of the standard) states that a plus sign must be used for a positive or zero value, and a minus sign for a negative value. Contrary to this rule, RFC 3339, which is otherwise a profile of ISO 8601, permits the use of "-00", with the same denotation as "+00" but a differing connotation

Since these are stated as separate requirements, I'd expect the LRS to validate that the timestamp is valid ISO 8601 and also valid RFC 3339, that is, the RFC 3339 SHOULD* would not be read to allow the negative zero offset. I suggest we add clarification to that effect, and then add a conformance test to reject a timestamp with a -00 offset.

[brianjmiller]

See #897 for original addition of the SHOULD*.

[garemoko]

Makes sense. I'd be interested to know how much usage of -00 timestamps there is in the wild. I feel like I've seen it at least once before.

Would I be right in thinking that this wouldn't be a breaking issue for existing data since the serialization of the timestamp is not what's immutable? (i.e. an LRS could happily convert -0000 timestamps in it's database if it needed to make them conformant)

[andyjohnson]

Per the 3/21/2018 call, participants agreed with the -00 violating a MUST requirement. Unless further discussed, the LRS Conformance Test will be updated with a few "bad timestamp" tests, like -00, and expect that an LRS reject those Statements. This will cause a new version of the Test Suite to be released.

[andyjohnson]

Also per the 3/21/2018 call, suggest for next version - some text that suggests that BOTH of the timestamp requirements are separate and that RFC 3339 is NOT a subset of ISO 8601. This results in cases where a behavior allowed in RFC3339 is not allowed in ISO8601, such as -00 referenced above.

[DataBeeGood]

Makes sense. I'd be interested to know how much usage of -00 timestamps there is in the wild. I feel like I've seen it at least once before.
Would I be right in thinking that this wouldn't be a breaking issue for existing data since the serialization of the timestamp is not what's immutable? (i.e. an LRS could happily convert -0000 timestamps in it's database if it needed to make them conformant)

@garemoko and @vbhayden who has pushed this to conformance and rightly so :)

Negative time stamps can be related to how various machines choose to track time.

This wiki summarizes some issues that may start popping up in old embedded sensors, internet servers, etc.

It also mentions the lazy programmer syndrome... who sets durations to be really long... but not controlled, causing a wrap around issue...

https://en.wikipedia.org/wiki/Year_2038_problem

[garemoko]

@DataBeeGood this issue relates not to negative timestamps, but to a negative timezone, specifically UTC minus 0 hours. Since minus 0 is equal to plus 0, the debate is if minus 0 is valid.