# ISO 8601 time values

**Category:** [Implementers (archive)](https://discourse.openehr.org/c/implementers-archive/158)
**Created:** 2006-09-20 13:40 UTC
**Views:** 5
**Replies:** 6
**URL:** https://discourse.openehr.org/t/iso-8601-time-values/14273

---

## Post #1 by @Andrew_Patterson

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

---

## Post #2 by @Magnus_Fogelberg

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

---

## Post #3 by @Andrew_Patterson

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

---

## Post #4 by @thomas.beale

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

---

## Post #5 by @thomas.beale

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

---

## Post #6 by @Magnus_Fogelberg

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

---

## Post #7 by @thomas.beale

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
>  

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

---


**Canonical:** https://discourse.openehr.org/t/iso-8601-time-values/14273
**Original content:** https://discourse.openehr.org/t/iso-8601-time-values/14273