search

amazon-ion / ion-docs

Source for the GitHub Pages for Ion.
https://amazon-ion.github.io/ion-docs/
Apache License 2.0
22 stars 22 forks source link

Clarify spec to disallow binary Ion timestamps with known offsets and less than minute precision #91

Open tgregg opened 4 years ago

tgregg commented 4 years ago

The text grammar is clear that a local offset is not representable unless the timestamp has at least minute precision. However, in binary Ion, local offsets are representable at any precision since the offset is the first subfield in the encoding. The spec is silent about which precision levels are allowed to have known offsets for binary timestamps.

The spec should explicitly prohibit binary timestamps below minute precision with known offsets, e.g. 62 E1 E1. The correct encoding for such a timestamp would be 62 C0 E1, indicating an unknown offset.

Before making the spec change, we need to determine two things:

  1. Whether any implementation incorrectly writes a known non-zero offset for low-precision timestamps when the timestamp provided by the user had a known offset. If this is the case, then we may have to take the more pragmatic approach of simply ignoring such offsets on read to avoid breaking existing data.
  2. Whether any implementation incorrectly writes low-precision timestamps with offset 0 (i.e. UTC), e.g. 62 80 E1 when the timestamp provided by the user had an unknown offset. If this is the case, for legacy reasons we'll probably need to treat offset 0 in low-precision timestamps as equivalent to unknown to avoid breaking tons of existing data.

Once we've committed to the spec language, we need to create issues in the repos for the affected implementations to:

  1. Raise an error (or ignore the offset, if that's what we decide) when an offset is encountered in a low-precision binary Ion timestamp.
  2. Raise an error when the writer receives a low-precision timestamp with a known offset (or when such a timestamp is constructed, whichever is more appropriate for the implementation).
almann commented 4 years ago

I am good with prohibiting nonzero offsets proviso what you've said. If we prohibit the offset for those cases, it should be error not ignore.

rmarrowstone commented 1 year ago

It's not clear to me that the right answer is to disallow "offset-aware" dates.

The W3C XSD date type allows an offset, for example, and the Java SE DateTimeFormatter parses such "offset-aware" dates: https://docs.oracle.com/javase/10/docs/api/java/time/format/DateTimeFormatter.html#ISO_OFFSET_DATE

If we disallow them, then yes, we need to be clear if they are to be ignored or result in a parse error when encountered.