I've mostly finished my implementation of the CE temporal types, and there are a number of points where the spec seemed ambiguous, so I used the empirical behavior of enctool to decide what to do, or just picked something.
For location time zones:
The first value is latitude with positive=north, and the second value is longitude with positive=east (based on one of the examples). In general, technical specs aren't consistent about the order of these two values, so I wouldn't assume readers would pick the same order. There's at least one place where CE says "longitude/latitude".
The + character is not allowed. That's consistent with other parts of CTE, but never specified here.
Leading 0s are allowed, but the max digits are 2.2/3.2, e.g., 1/1 or 01/001 is OK but 00001/00001 is not.
The . is optional, for each value, but if it's present, at least one digit must follow, e.g., 0./0. is invalid.
The Compact Time (i.e., CBE) spec says:
"Time zone values that contain different longitude/latitude values, but still refer to the same time zone at their particular time, are considered equal. For example: [48.85, 2.32] on Dec 10, 2010, and [48.90, 2.28] on Jan 1, 2000"
Since temporal types can be map keys, this would seem to suggest that any conforming CE decoder must have a complete map of the time zones of the world, accurate to 0.01°. Nope! Maybe I'll let the user provide their own equality function, or return every map as a multi-map and let the user sort it out.
For named time zones:
The IANA spec has a long list of "general guidelines", "in decreasing order of importance", and enctool seems stricter than the strictest interpretation of this, but more lenient than the most lenient interpretation. I'm using: "all ASCII", "all graphical characters", "length is 1-127" (before abbreviating), "doesn't start with [+-0-9]", which seems to work well enough for all the examples, and all the reasonable cases I could think of.
For offset time zones:
There's a limit of ±1439 minutes defined in Compact Time (CBE), only. I'm bumping this up to the CE layer so all encodings will use the same limit. enctool already enforces it for CTE.
For times:
As with location time zones, if there's a ., at least one digit is required to follow. This wasn't entirely clear to me from the table (Mandatory = N, Min Digits = 0).
Unlike with time zones, the CE spec never says exactly what time system is to be encoded. It allows seconds=60 for leap seconds, but I don't think any programming language or operating system I've ever used has supported those (they all use Unix Time) so I'm just clamping seconds to [0,59] when I read them.
I've mostly finished my implementation of the CE temporal types, and there are a number of points where the spec seemed ambiguous, so I used the empirical behavior of
enctoolto decide what to do, or just picked something.For location time zones:
+character is not allowed. That's consistent with other parts of CTE, but never specified here.0s are allowed, but the max digits are 2.2/3.2, e.g.,1/1or01/001is OK but00001/00001is not..is optional, for each value, but if it's present, at least one digit must follow, e.g.,0./0.is invalid.The Compact Time (i.e., CBE) spec says:
Since temporal types can be map keys, this would seem to suggest that any conforming CE decoder must have a complete map of the time zones of the world, accurate to 0.01°. Nope! Maybe I'll let the user provide their own equality function, or return every map as a multi-map and let the user sort it out.
For named time zones:
enctoolseems stricter than the strictest interpretation of this, but more lenient than the most lenient interpretation. I'm using: "all ASCII", "all graphical characters", "length is 1-127" (before abbreviating), "doesn't start with [+-0-9]", which seems to work well enough for all the examples, and all the reasonable cases I could think of.For offset time zones:
enctoolalready enforces it for CTE.For times:
., at least one digit is required to follow. This wasn't entirely clear to me from the table (Mandatory = N, Min Digits = 0).