# ISO 8601 time values

**URL:** <https://discourse.openehr.org/t/iso-8601-time-values/14273>\
**Category:** Implementers (archive)\
**Created:** [20 September 2006 13:40 UTC](https://discourse.openehr.org/t/iso-8601-time-values/14273 "2006-09-20T13:40:59Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Andrew\_Patterson](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/a/76d3ee/32.png) [@Andrew\_Patterson](https://discourse.openehr.org/u/Andrew_Patterson)\
**Post date:** [20 September 2006 13:40 UTC](https://discourse.openehr.org/t/iso-8601-time-values/14273/1 "2006-09-20T13:40:59Z")

</div>

I'm a bit confused about the ISO 8601 time values..  
when are they meant to be preceeded by a 'T' and  
when are they not? I understand that when you  
have a complete DateTime value, the 'T' character  
splits the date and time. But when you have a  
time by itself, I'm not sure what is meant to  
happen. The ADL documents seem to be  
inconsistent regarding this - and the reference  
grammar seems to have the T in the comment  
but then doesn't have it in the actual lex rules..

Andrew

---

<div class="post-metadata">

**Author:** ![Magnus\_Fogelberg](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/m/7993a0/32.png) [@Magnus\_Fogelberg](https://discourse.openehr.org/u/Magnus_Fogelberg)\
**Post date:** [20 September 2006 16:09 UTC](https://discourse.openehr.org/t/iso-8601-time-values/14273/2 "2006-09-20T16:09:46Z")

</div>

Dear Andrew,

The "T" is a designator for time, i.e. it must divide the date portion of a  
complete time expression from the time portion (YYYYMMDDThhmmss). If you state  
only time, this will be obvious because you use only 6 digits (and possibly a  
comma - not a period - and fractions of a secon) and probably a range of  
numbers which make it obvious that you talk about time and not date. So the  
time of the clock will always be written hhmmss without a T.

We have had a discussion about the use of the extended date notation (YYYY-MM-  
DD), which I consider to be deprecated in communication of date and time  
information.

Cheers

Magnus

Citerar Andrew Patterson \<andrewpatto@gmail.com\>:

I'm a bit confused about the ISO 8601 time values..  
when are they meant to be preceeded by a 'T' and  
when are they not? I understand that when you  
have a complete DateTime value, the 'T' character  
splits the date and time. But when you have a  
time by itself, I'm not sure what is meant to  
happen. The ADL documents seem to be  
inconsistent regarding this - and the reference  
grammar seems to have the T in the comment  
but then doesn't have it in the actual lex rules..

Andrew

---

<div class="post-metadata">

**Author:** ![Andrew\_Patterson](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/a/76d3ee/32.png) [@Andrew\_Patterson](https://discourse.openehr.org/u/Andrew_Patterson)\
**Post date:** [21 September 2006 03:27 UTC](https://discourse.openehr.org/t/iso-8601-time-values/14273/3 "2006-09-21T03:27:42Z")

</div>

section 4.4.6 on the ADL spec says

NB: for the following constraint types, parser writers should consider  
allowing the 'T'  
character to be optional on read but mandatory on save for some time.  
This is because  
previous versions of ADL did not include it, with the result that  
existing tools have created  
archetypes without the 'T' in date/time constraint patterns.

---

<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:** [21 September 2006 17:16 UTC](https://discourse.openehr.org/t/iso-8601-time-values/14273/4 "2006-09-21T17:16:53Z")

</div>

Magnus Fogelberg wrote:

> Dear Andrew,
> 
> The "T" is a designator for time, i.e. it must divide the date portion of a  
> complete time expression from the time portion (YYYYMMDDThhmmss). If you state  
> only time, this will be obvious because you use only 6 digits (and possibly a  
> comma - not a period - and fractions of a secon) and probably a range of  
> numbers which make it obvious that you talk about time and not date. So the  
> time of the clock will always be written hhmmss without a T.  
> &nbsp;&nbsp;

yes, this is correct according to ISO8601:2004, and is what is used in  
openEHR. However, we didn't originally get this right, so there may be  
leftover ambiguities in the text, which I am of course keen to locate.

> We have had a discussion about the use of the extended date notation (YYYY-MM-  
> DD), which I consider to be deprecated in communication of date and time  
> information.

Well, it isn't deprecated in the most recent ISO8601 standard, and it is  
actually more parser-friendly in circumstances when typing information  
is not available. Why do you see it as deprecated?

- thomas

---

<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:** [21 September 2006 17:36 UTC](https://discourse.openehr.org/t/iso-8601-time-values/14273/5 "2006-09-21T17:36:28Z")

</div>

I think we are probably wrong with the leading 'T' for times (not  
date-times). Going back to where we changed this, we did a CR to fix  
things:  
[http://coruscant.chime.ucl.ac.uk:8200/openEHR\_Collector/projects/specifications/CR/213](http://coruscant.chime.ucl.ac.uk:8200/openEHR_Collector/projects/specifications/CR/213)  
because previously we had no 'T's at all in ADL. But as you can from the  
CR and the ADL doc, we have erroneously put a leading 'T' on  
time-constraint patterns as well - I think I did this from our earlier  
understanding of ISO8601, but we (UCL) obtained a 2004 copy and we fixed  
this in most places (like in dADL and in the Support IM), but obviously  
I didn't get it right here.

I can't think of any other reason why this would be like this, so I'll  
do a bit more checking and correct this detail.

Re: the case-sensitivity, I'll have to check the standard again as to  
whether it is truly case-sensitive or not, and ensure we follow what it  
says.

Thanks for the detailed feedback Andrew

- thomas

Andrew Patterson wrote:

---

<div class="post-metadata">

**Author:** ![Magnus\_Fogelberg](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/m/7993a0/32.png) [@Magnus\_Fogelberg](https://discourse.openehr.org/u/Magnus_Fogelberg)\
**Post date:** [21 September 2006 17:44 UTC](https://discourse.openehr.org/t/iso-8601-time-values/14273/6 "2006-09-21T17:44:11Z")

</div>

Hi Thomas,

In my ideal world we use one only format, which should be the first line in a  
standard. The extended form should be (is not actually, I know) deprecated in  
communication between systems, which would make parsing unambiguous. But in  
user interfaces the extended for may add clarity. I would say that information  
about the data type should make parsing clear, not the notation. I know that  
the problem is that some systems stubbornly consider a line of numeric  
characters as an integer, so it must always be made clear to the parser that  
date (and time) is a specialisation of string.

Magnus

Citerar Thomas Beale \<Thomas.Beale@oceaninformatics.biz\>:

Magnus Fogelberg wrote:  
\> Dear Andrew,  
\>  
\> The "T" is a designator for time, i.e. it must divide the date portion of a

\> complete time expression from the time portion (YYYYMMDDThhmmss). If you  
state  
\> only time, this will be obvious because you use only 6 digits (and possibly  
a  
\> comma - not a period - and fractions of a secon) and probably a range of  
\> numbers which make it obvious that you talk about time and not date. So the

\> time of the clock will always be written hhmmss without a T.  
\>  
yes, this is correct according to ISO8601:2004, and is what is used in  
openEHR. However, we didn't originally get this right, so there may be  
leftover ambiguities in the text, which I am of course keen to locate.  
\> We have had a discussion about the use of the extended date notation  
(YYYY-MM-  
\> DD), which I consider to be deprecated in communication of date and time  
\> information.  
\>  
\>  
Well, it isn't deprecated in the most recent ISO8601 standard, and it is  
actually more parser-friendly in circumstances when typing information  
is not available. Why do you see it as deprecated?

- thomas

---

<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:** [25 September 2006 15:43 UTC](https://discourse.openehr.org/t/iso-8601-time-values/14273/7 "2006-09-25T15:43:25Z")

</div>

Andrew Patterson wrote:

> I'm a bit confused about the ISO 8601 time values..  
> when are they meant to be preceeded by a 'T' and  
> when are they not? I understand that when you  
> have a complete DateTime value, the 'T' character  
> splits the date and time. But when you have a  
> time by itself, I'm not sure what is meant to  
> happen. The ADL documents seem to be  
> inconsistent regarding this - and the reference  
> grammar seems to have the T in the comment  
> but then doesn't have it in the actual lex rules..
> 
> Andrew  
> &nbsp;&nbsp;

I have now corrected this, so that a leading 'T' on a time constraint  
pattern is tolerated on read, but removed on write. This will cause  
current archetypes with this error that are read and saved by either the  
Ocean Archetype Editor or the ADL workbench to silently be converted to  
the correct form. The ADL manuals have also been correct, but the  
changes are not yet online.

- thomas