# Timezone of ISO 8601 Date **Category:** [Specifications](https://discourse.openehr.org/c/specifications/6) **Created:** 2023-08-14 20:52 UTC **Views:** 1220 **Replies:** 9 **URL:** https://discourse.openehr.org/t/timezone-of-iso-8601-date/4353 --- ## Post #1 by @jmewes Hi there, The [Iso8601_date](https://specifications.openehr.org/releases/BASE/Release-1.2.0/foundation_types.html#_iso8601_date_class) class defined in the `time` package of the [Foundation Types](https://specifications.openehr.org/releases/BASE/Release-1.2.0/foundation_types.html) specification has a function `timezone()` that returns a value of type [Iso8601_timezone](https://specifications.openehr.org/releases/BASE/Release-1.2.0/foundation_types.html#_iso8601_timezone_class). As far as I understand the [ISO 8601](https://en.wikipedia.org/wiki/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 --- ## Post #2 by @sebastian.garde 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. --- ## Post #3 by @jmewes In the [Joda-Time](https://www.joda.org/joda-time) library (Java) I found the function [ISODateTimeFormat.html#dateParser](https://www.joda.org/joda-time/apidocs/org/joda/time/format/ISODateTimeFormat.html#dateParser--) which can handle "dates with a possible zone". In the [corresponding unit test](https://github.com/JodaOrg/joda-time/blob/75ab8caeaadb6ffcef7726c1bc38ed0ee3b0eb18/src/test/java/org/joda/time/format/TestISODateTimeFormatParsing.java#L71) they have the following dates with a zone: - 2006-06-09T+02:00 - 2006-W27-3T+02:00 - 2006-123T+02:00 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. --- ## Post #4 by @sebastian.garde True and possibly useful - however openEHR's `Time_definitions.valid_iso8601_date()` does not allow this as far as I can see. ![image|690x264](upload://zn0sGZQE9kEMQBGsRWFGGnfTSRr.png) --- ## Post #5 by @ian.mcnicoll Might there be some edge cases where the date/tz is critical, e.g in a region where there are 2 adjacent timezones? --- ## Post #6 by @thomas.beale [quote="jmewes, post:1, topic:4353"] Why do we need the timezone as part of the `Iso8601_date` class? How would a date value with a time zone look like? [/quote] 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. [quote="sebastian.garde, post:4, topic:4353"] True and possibly useful - however openEHR’s `Time_definitions.valid_iso8601_date()` does not allow this as far as I can see. [/quote] Yep you are right - could you please raise a CR directly in BASE to fix that? I can fix it easily in the specs. --- ## Post #7 by @jmewes I can't create a CR, but as suggested by Sebastian, I have created a PR: > Missing timezone in description of ISO 8601 date https://openehr.atlassian.net/browse/SPECPR-426 --- ## Post #8 by @sebastian.garde The guy providing the accepted answer here thinks that timezones are NOT officially supported for date by ISO8601. https://stackoverflow.com/questions/52215961/how-can-i-write-an-iso-8601-date-with-a-timezone-but-no-time-component 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. see https://en.wikipedia.org/wiki/ISO_8601 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. https://specifications.openehr.org/releases/AM/Release-2.2.0/ADL2.html#_constraints_on_dates_times_and_durations https://specifications.openehr.org/releases/AM/Release-2.2.0/ADL1.4.html#_base_lexer --- ## Post #9 by @jmewes > 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. --- ## Post #11 by @jmewes In section 5.5.1 about "Time interval" there is actually an example that uses the time shift right after a date. --- **Canonical:** https://discourse.openehr.org/t/timezone-of-iso-8601-date/4353 **Original content:** https://discourse.openehr.org/t/timezone-of-iso-8601-date/4353