Hi there,
The Iso8601_date class defined in the time package of the Foundation Types specification has a function timezone() that returns a value of type Iso8601_timezone.
As far as I understand the ISO 8601 standard, the timezone is related to the time part, not to the date part.
Why do we need the timezone as part of the Iso8601_date class? How would a date value with a time zone look like?
Best regards,
Jan
Hi Jan,
It states that it can be void and thus is probably not causing practical problems, but like you I am not sure why it exists at all for date…also given that there is no way to syntactically express the timezone as part of the date.
But I may very well be missing something…dates and times are extremely complex once you go into the details.
If nobody else replies here with an explanation, I would suggest that you raise this as a PR on openEHR Jira tracker.
In the Joda-Time library (Java) I found the function ISODateTimeFormat.html#dateParser which can handle “dates with a possible zone”.
In the corresponding unit test they have the following dates with a zone:
So, most likely this pattern is defined in a part of the standard that is not covered by the Wikipedia article and other freely accessible resources.
True and possibly useful - however openEHR’s Time_definitions.valid_iso8601_date() does not allow this as far as I can see.
Might there be some edge cases where the date/tz is critical, e.g in a region where there are 2 adjacent timezones?
My memory of defining this is that I did discover situations where dates with TZ are required, I believe from US military or similar. It does seem reasonable to me, since the date at some moment in time does depend on the timezone.
Consider a clinical event (e.g. stroke) recorded date = 02 Aug 2022 TZ +1000 (let’s say Sydney) really means that at some time between UTC 14:00 on 01 Aug 2022 and UTC and 14:00 on 02 Aug 2022, that the stroke was experienced.
For military personnel crossing time-zones by air, this kind of thing might matter.
Yep you are right - could you please raise a CR directly in BASE to fix that? I can fix it easily in the specs.
I can’t create a CR, but as suggested by Sebastian, I have created a PR:
Missing timezone in description of ISO 8601 date
The guy providing the accepted answer here thinks that timezones are NOT officially supported for date by ISO8601.
Java seems to think so though.
https://docs.oracle.com/javase/10/docs/api/java/time/format/DateTimeFormatter.html#ISO_OFFSET_DATE
Is there someone with access to the standard itself who can have a close look?
Also, if we claim full compliance with ISO8601, the week dates
such as YYYY-Www or YYYY-Www-D
and ordinal dates such as YYYY-DDD would need to be part of this as well.
I am not sure we want week dates or ordinal dates?
If not we may consider rephrasing the conformance from “is a valid ISO 8601 date” to “is a valid ISO 8601 calendar date”
In any case, timezones as well as week or ordinal dates will likely also affect the Base Lexers and week and ordinal dates the constraint patterns as well.
Is there someone with access to the standard itself who can have a close look?
I got the opportunity to skim and search “ISO 8601-1 First edition 2019-02”.
As far as I can tell, the “time shift”, as they call the time zone declaration, is only applicable to time.
In section 5.5.1 about “Time interval” there is actually an example that uses the time shift right after a date.
