# Timezone of ISO 8601 Date

**URL:** <https://discourse.openehr.org/t/timezone-of-iso-8601-date/4353>\
**Category:** Specifications\
**Tags:** base\
**Created:** [14 August 2023 20:52 UTC](https://discourse.openehr.org/t/timezone-of-iso-8601-date/4353 "2023-08-14T20:52:27Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![jmewes](https://discourse.openehr.org/user_avatar/discourse.openehr.org/jmewes/32/66_2.png) [@jmewes](https://discourse.openehr.org/u/jmewes)\
**Post date:** [14 August 2023 20:52 UTC](https://discourse.openehr.org/t/timezone-of-iso-8601-date/4353/1 "2023-08-14T20:52:27Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![sebastian.garde](https://discourse.openehr.org/user_avatar/discourse.openehr.org/sebastian.garde/32/3070_2.png) [@sebastian.garde](https://discourse.openehr.org/u/sebastian.garde)\
**Post date:** [15 August 2023 11:53 UTC](https://discourse.openehr.org/t/timezone-of-iso-8601-date/4353/2 "2023-08-15T11:53:00Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![jmewes](https://discourse.openehr.org/user_avatar/discourse.openehr.org/jmewes/32/66_2.png) [@jmewes](https://discourse.openehr.org/u/jmewes)\
**Post date:** [15 August 2023 20:29 UTC](https://discourse.openehr.org/t/timezone-of-iso-8601-date/4353/3 "2023-08-15T20:29:47Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![sebastian.garde](https://discourse.openehr.org/user_avatar/discourse.openehr.org/sebastian.garde/32/3070_2.png) [@sebastian.garde](https://discourse.openehr.org/u/sebastian.garde)\
**Post date:** [16 August 2023 06:50 UTC](https://discourse.openehr.org/t/timezone-of-iso-8601-date/4353/4 "2023-08-16T06:50:43Z")

</div>

True and possibly useful - however openEHR’s `Time_definitions.valid_iso8601_date()` does not allow this as far as I can see.

 ![image](https://discourse.openehr.org/uploads/default/original/2X/f/f7e5e2b5cc6deedd561272358d2e5cd0ee9baba1.png)

---

<div class="post-metadata">

**Author:** ![ian.mcnicoll](https://discourse.openehr.org/user_avatar/discourse.openehr.org/ian.mcnicoll/32/4430_2.png) [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)\
**Post date:** [16 August 2023 07:49 UTC](https://discourse.openehr.org/t/timezone-of-iso-8601-date/4353/5 "2023-08-16T07:49:45Z")

</div>

Might there be some edge cases where the date/tz is critical, e.g in a region where there are 2 adjacent timezones?

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [16 August 2023 17:02 UTC](https://discourse.openehr.org/t/timezone-of-iso-8601-date/4353/6 "2023-08-16T17:02:30Z")

</div>

> [@jmewes](#):
>
> Why do we need the timezone as part of the `Iso8601_date` class? How would a date value with a time zone look like?

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.

> [@sebastian.garde](#):
>
> True and possibly useful - however openEHR’s `Time_definitions.valid_iso8601_date()` does not allow this as far as I can see.

Yep you are right - could you please raise a CR directly in BASE to fix that? I can fix it easily in the specs.

---

<div class="post-metadata">

**Author:** ![jmewes](https://discourse.openehr.org/user_avatar/discourse.openehr.org/jmewes/32/66_2.png) [@jmewes](https://discourse.openehr.org/u/jmewes)\
**Post date:** [16 August 2023 21:01 UTC](https://discourse.openehr.org/t/timezone-of-iso-8601-date/4353/7 "2023-08-16T21:01:49Z")

</div>

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](https://openehr.atlassian.net/browse/SPECPR-426)

---

<div class="post-metadata">

**Author:** ![sebastian.garde](https://discourse.openehr.org/user_avatar/discourse.openehr.org/sebastian.garde/32/3070_2.png) [@sebastian.garde](https://discourse.openehr.org/u/sebastian.garde)\
**Post date:** [17 August 2023 06:42 UTC](https://discourse.openehr.org/t/timezone-of-iso-8601-date/4353/8 "2023-08-17T06:42:13Z")

</div>

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](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 [ISO 8601 - Wikipedia](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.

> **[Archetype Definition Language 2 (ADL2)](https://specifications.openehr.org/releases/AM/Release-2.2.0/ADL2.html#_constraints_on_dates_times_and_durations)**
>
> openEHR Archetype Definition Language 2 (ADL2)

> **[Archetype Definition Language 1.4 (ADL1.4)](https://specifications.openehr.org/releases/AM/Release-2.2.0/ADL1.4.html#_base_lexer)**
>
> openEHR Archetype Definition Language 1.4 (ADL1.4) (ISO 13606-2:2008)

---

<div class="post-metadata">

**Author:** ![jmewes](https://discourse.openehr.org/user_avatar/discourse.openehr.org/jmewes/32/66_2.png) [@jmewes](https://discourse.openehr.org/u/jmewes)\
**Post date:** [22 July 2024 07:04 UTC](https://discourse.openehr.org/t/timezone-of-iso-8601-date/4353/9 "2024-07-22T07:04:32Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![jmewes](https://discourse.openehr.org/user_avatar/discourse.openehr.org/jmewes/32/66_2.png) [@jmewes](https://discourse.openehr.org/u/jmewes)\
**Post date:** [22 July 2024 07:29 UTC](https://discourse.openehr.org/t/timezone-of-iso-8601-date/4353/11 "2024-07-22T07:29:36Z")

</div>

In section 5.5.1 about “Time interval” there is actually an example that uses the time shift right after a date.

---

<div class="post-metadata">

**Author:** ![sebastian.iancu](https://discourse.openehr.org/user_avatar/discourse.openehr.org/sebastian.iancu/32/31_2.png) [@sebastian.iancu](https://discourse.openehr.org/u/sebastian.iancu)\
**Post date:** [24 July 2026 11:59 UTC](https://discourse.openehr.org/t/timezone-of-iso-8601-date/4353/12 "2026-07-24T11:59:27Z")

</div>

I bumped into this SPECPR-426 and solved it now by removing the timezone() from the date - I think is in line with most of implementations.

> <https://github.com/openEHR/specifications-BASE/pull/23>
>
> \## SPECPR-426 — remove \`timezone()\` from \`Iso8601\_date\`
> 
> Reported by \*\*Jan Mewes…\*\* (\[SPECPR-426\](https://openehr.atlassian.net/browse/SPECPR-426)).
> 
> \### Problem
> \`Iso8601\_date\` exposed a \`timezone(): Iso8601\_timezone\` function ("\_Timezone; may be Void\_"), yet neither the class value-format documentation nor \`Time\_definitions.valid\_iso8601\_date()\` mentions or permits a timezone — an internal contradiction. \`Iso8601\_date\_time\` and \`Iso8601\_time\` correctly document and validate a timezone; \`Iso8601\_date\` was the outlier.
> 
> \### Resolution
> An ISO 8601 \*\*date\*\* does not carry a timezone — the time shift applies to the \*time\* part only (ISO 8601-1:2019; the standalone calendar date has no zone designator). The \`timezone()\` accessor on \`Iso8601\_date\` was a carry-over from \`Iso8601\_date\_time\` / \`Iso8601\_time\`. This PR \*\*removes it\*\* from the BMM and regenerates the class table.
> 
> This follows the working-group inclination in the discourse discussion \[\_Timezone of ISO 8601 date\_\](https://discourse.openehr.org/t/timezone-of-iso-8601-date/4353), where the reading of ISO 8601-1:2019 is that the time shift applies to time, not dates, and \`valid\_iso8601\_date()\` never accepted a zone anyway.
> 
> \### Scope / safety
> \- \`Iso8601\_date\_time\` and \`Iso8601\_time\` \*\*retain\*\* their \`timezone()\` — unchanged.
> \- The accessor was introduced with the BMM (SPECBASE-48) and has \*\*never been in a released BASE version\*\*, so this is not a breaking change to any shipped spec.
> \- No invariant or other function on \`Iso8601\_date\` referenced \`timezone\`; the ancestor \`Iso8601\_type\` does not declare it.
> 
> \### Changes
> \- \`computable/BMM/openehr\_base\_1.3.0.bmm.json\` — remove the \`timezone\` function from \`Iso8601\_date\`.
> \- \`docs/UML/classes/org.openehr.base.foundation\_types.iso8601\_date.adoc\` — regenerated (via \`bmm-publisher\`).
> \- \`docs/foundation\_types/master00-amendment\_record.adoc\` — new \`1.3.4\` entry (raiser: J Mewes).
> 
> 🤖 Generated with \[Claude Code\](https://claude.com/claude-code)
> 
> 
> \[SPECPR-426\]: https://openehr.atlassian.net/browse/SPECPR-426?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ