ISO 8601-compatible constraint on instances of Date_Time not well supported in grammar.
Description
Activity
Bert Verhees April 28, 2016 at 9:05 AM
Resuming
Short versions of DATE and TIME are not possible to support in ADL, because the parser will confuse them with integers.
The DATE_TIME however can be (and will be in my grammar) supported in extended version and in short version, with "T" or with Space instead, and with comma or dot as a separator between the time element and its fraction.
Bert Verhees April 20, 2016 at 3:26 PM(edited)
I think, best is to follow the ISO-standard, and that standard gives some options. A problem is the pattern, I suggest they have the same options.
Then I can move on from now.
If wise women and men of the OpenEHR organization decide other ways, it is easier to restrict then to extent
Remarks:
1) We cannot have a short date-representation, nor a short time representation. This is because:
1985-06-02 is recognizable as a date, but 19850602 is not. It will be seen as an integer. The same problem for time-notation. So we cannot follow the ISO standard in this part, it is impossible.
We can follow the ISO short (non-extended) data-time-format because it exists of two integers with a space or a T between them, which can be recognized therefore as a DateTime.
But because we cannot do that for Date and Time, it is maybe better not to allow it for DateTime for consistency reasons.
Former user April 20, 2016 at 10:17 AM
I feel too many options for formatting is a bad idea - I would keep the T mandatory.
Ian McNicoll April 20, 2016 at 10:07 AM
I have been able to look at a fair proportion of the canonical composition serialisations in use by different implementers and most ?all are using the T separator between date and time.
Bert Verhees April 20, 2016 at 10:06 AM
I assume the pattern-constraints remain the same, or will they also have a extended and short version, and with or without "T"?
Details
Details
Reporter
Bert VerheesComponents
Priority
Major
I have no access to the original ISO document, so I must use information from wikipedia, etc.
The grammar formulates like this:
ISO8601_DATE_TIME : YEAR '' MONTH '' DAY 'T' HOUR (':' MINUTE (':' SECOND ( ',' DIGIT+ )?)?)? ( TIMEZONE )? ;
This is OK, although the ISO also permits a "." between SECOND and DIGIT.
The problem is in TIMEZONE, it is defined like this:
fragment TIMEZONE : 'Z' | ('+'|'-') HOUR_MIN ;
fragment HOUR_MIN : ( [01]?[0-9] | [2][0-3] ) [0-5][0-9] ;
First, the ISO format can write HOUR_MIN as f.e. 7:30 but also as 730
And the minutes from the time-zone are not necessary when the zone is a full number.
So these notations are valid:
2007-04-05T12:30.123-02:00
2007-04-05T12:30.123-0200
2007-04-05T12:30,123-02:00
2007-04-05T12:30,123-0200
2007-04-05T12:30.123-02
2007-04-05T12:30,123-02
So time-zone can be written like this:
fragment HOUR_MIN : HOUR ( ':'? MINUTE )? ;
And ISO_DATE_TIME like this:
ISO8601_DATE_TIME : YEAR '' MONTH '' DAY 'T' HOUR (':' MINUTE (':' SECOND ( ',' DIGIT+ )?)?)? ( TIMEZONE )? | YEAR '' MONTH '' DAY 'T' HOUR (':' MINUTE (':' SECOND ( '.' DIGIT+ )?)?)? ( TIMEZONE )? ;
ISO also permits removing all other punctuation marks, and removing the T, but maybe this is already good enough to get the Russians confused.