Remove ambiguity in ISO8601_TIME Class on fractional seconds


ISO8601 spec allows for capturing time down to microseconds (0.000001) - that is 6 digits after decimal point. While current RM ISO8601_TIME Class defines Real type to capture fractional seconds there's potentially conflicting information which depicts: hh:mm:ss[,sss][Z | ±hh[mm]] (Note 3 fractional digits which can only cater for milliseconds)
It seems at least one implementation (Marand) is not saving >3 digits after decimal point so they may have implemented this as a constraint.
I suggest revising these format statements as: hh:mm:ss[,ssssss][Z | ±hh[mm]] And also providing accompanying text to clarify this is not a limitation and values for microseconds (and possibly beyond) should be supported.
Ocean's Archetype Editor also provide microseconds as an option to define Event's periodicity and to define Interval duration but fail to save with Archetype (Hence is a bug).




Thomas Beale
February 22, 2016, 4:49 PM

If we assume that the limit is not microseconds either, then I am inclined to leave the 'sss' as it is and just make the text clearer.

Koray Atalag
February 23, 2016, 12:11 AM

Hmm then there's the danger of implementers simply allowing 3 digits after decimal sign which currently seems to be the problem. Making the text clearer will definitely help - perhaps if we put an explicit statement that sss is not a limit but just for example's sake.

Thomas Beale
February 23, 2016, 5:16 PM

Well, we could put 'ssssss' but then will implementers think they have to always handle six decimal digits ? The other way is something like s+ which is proper regex....

Koray Atalag
February 23, 2016, 10:33 PM

Hi Tom, I like the proper way: s+
That's exactly what's happening with sss - the implementers have just done that!



Koray Atalag




Affects versions