Remove ambiguity in ISO8601_TIME Class on fractional seconds

Description

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).

Environment

N/A

Activity

Koray Atalag February 23, 2016 at 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!

Thomas Beale February 23, 2016 at 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 at 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 22, 2016 at 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.

Done

Details

Reporter

Components

Affects versions

Priority

Created February 2, 2016 at 8:55 PM
Updated March 9, 2016 at 11:35 PM
Resolved March 9, 2016 at 11:35 PM