Improve specification of constraint patterns in temporal constraint classes

@Sebastian Garde and @Sebastian Garde I’ve fixed the TZ constraint table in ADL2 and ADL1.4. specs to allow ‘Z' as a literal constraint. I’ve also removed the inline rules, and replaced with refs to the grammars included further down. CHanges to those grammars are pushed as well. See last 3 commits.

@Sebastian Garde , @Thomas Beale , my hypothetical use case is the following:

A pan-european registry of a specific disease uses an openEHR platform to record all their data. Such data might be using dates in 3 TZs (for instance from UK, NL/DE, RO). If the platform API is not trusting the clients dealing correctly with localized time, it might be necessary to enforce/constrain the use of datetime in UTC format exclusively (which implies that platform-clients have to do the conversions when read/write data). How can we (openEHR SEC) support expressing this constraint? How should the platform (via archetypes/templates) enforce use of only UTC in client/server communication or data instances?

My solution would have been to support 'Z' literal constant as a TZ pattern. This would mean that only UTC dates are valid, thus without any explicit h/m TZ.

Does a timezone pattern of

mean you are not allowed to add minutes for the few places that have 1/2 or 3/4 hour offsets (and if so why would we exclude them)?

In any case, wouldn’t it be easier to follow the same patterns as used for the time, e.g. hh:mm, hh:??, (and if need be: hh:XX)?

–

Re @Sebastian Iancu's comment on timezone ‘Z': I don’t have a strong opinion either way, but just want to point out that currently 'Z’ is not allowed in TZ_PATTERN, but in the pattern explanation underneath, it states that “full timezone modifier required, commencing with '+' or '-'; 'Z' also allowed”. which seems slightly inconsistent.

I can’t really see why anyone would need to constrain the TZ specifically to ‘Z' - that’s only for UTC, and how TZ is actually recorded will just depend on apps or other software - it might be ‘Z', it might be ‘+00’, ‘+0000’ or ‘+00:00’ (I think even ‘-00’ etc must be legal as well). I think ‘Z’ is an anomaly in ISO 8601 one (= a bad idea!) and I think making it possible to constrain to that particular representation of UTC TZ could enable clinical modellers to use it, when they don’t realise it could be recorded in a number of other ways.

I think is better. But what if for instance, someone will like to constrain the timezone to ‘Z' exclusively, i.e. only UTC datetimes are valid - how can you do that? The ‘X’ cannot be used for this, isn’t it? Should then in such case the pattern allow the use of 'Z' (as timezone pattern)? In that case the fragment may be something like:

fragment TZ_PATTERN : 'Z' | '±' ('hh' | 'HH') (':'? ('mm' | 'MM'))? ;