- Please let's move 4.4.3.3 (scalar-unit) into 4.4.2. The scalar-unit types are special types, not collection types.
- I propose adding a "timestamp" type to section 4.4.2. As we discussed, this was missing in my previous rewrite.
I also want to raise a question:
Do we want the comparison constraints to work for strings? E.g. should "greater_than" do a sorting-based comparison? I'll just point that it is non-trivial to sort Unicode strings. The most common way is to use the Unicode Collation Algorithm, which involves a database of information. There is a reference implementation in
ICU. Good and proper Unicode libraries will support it (e.g.
here is Go's), but I do imagine it may be a burden for some implementations. I suggest we discuss this in the ad hoc and consider the pros and cons.
Here is my proposed text for timestamp:
4.4.2.x TOSCA timestamp type
A local instant in time containing two elements: the local notation plus the timezone offset.
TOSCA timestamps are represented as strings following [
RFC 3339], which in turn uses a simplified profile of [
ISO 8601]. TOSCA adds an exception to RFC 3339: though RFC 3339 supports timestamps with
unknown local offsets, represented as the "-0" timezone, TOSCA
does not support this feature and will treat the unknown timezone as UTC. There are two reasons for this exception: the first is that many systems do not support this distinction and TOSCA aims for interoperability, and the second is that timestamps with unknown timezones cannot be converted to UTC, making it impossible to apply comparison constraints. If this feature is required it can be supported via a custom data type (see XXX).
Notes:
- The TOSCA constraints "equal", "greater_than", "greater_or_equal", "less_than", and "less_or_equal" all use the universal instant, i.e. as the local instant is converted to UTC by applying the timezone offset.
- Some YAML implementations may support the !!timestamp type working draft, but to ensure portability TOSCA implementations shall not accept this YAML type. Also note that the YAML !!timestamp supports a relaxed notation with whitespace, which does not conform to RFC 3339.
- RFC 3339 is based on the Gregorian calendar, including leap years and leap seconds, and is thus explicitly culturally biased. It cannot be used for non-Gregorian locales. Other calendar representations can be supported via custom data types (see XXX).
- Timezone information is expressed and stored numerically as an offset from UTC, thus daylight savings and other local changes are not included.
- TOSCA does not specify a canonical representation for timestamps. The only requirement is that representations adhere to RFC 3339.