Allow timestamp ranges to have endpoints with unknown offsets

[popematt]

According to the spec,

When a timestamp range is specified, neither end of the range may have an unknown local offset.

It seems like it ought to be possible to specify a range of timestamps with unknown local offset as long as both ends of the range have an unknown offset.

It would probably be acceptable to say that a timestamp range with known offsets can only contain other timestamps with known offsets, and a timestamp range with unknown offsets can only contain timestamps with unknown offsets.

[popematt]

It was brought to my attention that the Ion specification says:

If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of “-00:00”.

Specifically, I want to call attention to the fact that for a timestamp with unknown offset, the time in UTC is known, and so by implication, timestamps with unknown offset should be comparable to timestamps with a known offset.

[popematt]

Proposal

Motivation

In Ion Schema 1.0, it is impossible to model timestamp ranges that can accept a timestamp with a year, month, or day precision. For example, this customer_birth_date is not valid ISL 1.0.

type::{
  name: customer_birth_date,
  // Don't allow birth dates before 1900 since there are no living people that old
  valid_values: range::[1900-01-01T, max],
  timestamp_precision: day,
}

If the range was changed to range::[1900-00-00T00:00:00Z, max], it would be valid, but it would be an unsatisfiable type because timestamps with a precision of year, month, and day always have an unknown offset, AND timestamps with an unknown offset cannot match any timestamp range.

This behavior is confusing, it seems to have no justification (see #36), and it prevents Ion Schema from being used for some legitimate use cases.

Changes

In a future version of Ion Schema, we should introduce the following changes to timestamp ranges:

• For Ion Schema, all non-null timestamps shall be comparable to any other non-null timestamp.
• Non-null timestamps shall be compared by normalizing them to an equivalent point in time in UTC.
• A timestamp range may be constructed using any non-null Ion timestamp values such that the lower bound is less than or equal to the upper bound. (Use of the min and max symbols remains unchanged.)
• Timestamp ranges where the upper and lower boundaries have different offsets shall be allowed, but mixing offsets should be discouraged by a linter rule.

[popematt]

Resolved by #76 in Ion Schema 2.0