Q: What's the allowed length for dateTime 'CCYY-MM-DDThh:mm:ss.sss'

[Nickv]

Hello all!

I'm having some discussions at work and need some clarification/help 🙂 

I'm currently working on XML PACS files (pacs.008.001.02) where timestamps are being used.
One of the tags is CreDtTm - Creation Date Time.
A simple timestamp as far as I'm aware…

Please see XSD scheme definition below:

<xs:schema xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.02" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.02" elementFormDefault="qualified">
...
<xs:element name="CreDtTm" type="ISODateTime"/>
...
<xs:simpleType name="ISODateTime"> 
    <xs:restriction base="xs:dateTime"/> 
</xs:simpleType>

xs:dateTime should be in format 'CCYY-MM-DDThh:mm:ss.sss' if I'm correct?

The issue now is, if I check my input XML file with the corresponding XSD and the tag filled in like (mind the year 22019)

 <CreDtTm>22019-10-09</CreDtTm> 

XMLSpy says it's valid.
Even if I change the content to something rediculous, e.g. 220000000000019-10-09 XMLSpy says it's valid.

Does the CC mean it is a variable lenght and not restricted to 2 digits?

Please advice 🙂

Thanks a lot in advance!

[Funce]

This is a speculative post based on my observations.

It looks like rather than being constrained by any number of characters, it looks like the date format just instead needs to be delimited as allowed in the format. The letter examples seem to be merely common representations of how it is outputted.

In terms of what CC means, I believe it might be referring to the century, rather than the standard year.

I suspect that this might also be valid as a DateTime

1-1-1T1:1:1.1

and conversely

999999999-12-31T23:59:59.999999999999

See if you can check the above also. I'd be interested to see if there's a limit. I imagine if there isn't an arbitrary limit, the only limiting factor would be the max length of a string that is allowed to be put in.

[Nickv]

On 10/15/2019 at 12:16 AM, Funce said:

This is a speculative post based on my observations.

It looks like rather than being constrained by any number of characters, it looks like the date format just instead needs to be delimited as allowed in the format. The letter examples seem to be merely common representations of how it is outputted.

In terms of what CC means, I believe it might be referring to the century, rather than the standard year.

I suspect that this might also be valid as a DateTime

1-1-1T1:1:1.1

and conversely

999999999-12-31T23:59:59.999999999999

See if you can check the above also. I'd be interested to see if there's a limit. I imagine if there isn't an arbitrary limit, the only limiting factor would be the max length of a string that is allowed to be put in.

Thanks for your reply.

Indeed, the terms CC is referring to the century, together with the next YY it combines the year in total.

I've just tested the date given by you but I'm afraid it is not valid.
It seems that the year (CCYY) needs to have a minimum of 4 characters. Same for the other items, MM & DD

1111-11-11T11:11:11.1

Is valid.

This makes it hard to validate the receiving files from other parties. Because we validate each incoming file with the ISO XSD.
If the sender sends the file with a dateTime like 

111111-11-11T11:11:11.1

Then our internal processing will go in Error. 

We may not adjust the ISO XSD-scheme, but I think we need to adapt our internal processing to comply with these cases.

[Funce]

Interesting observation, thanks for clarifying my test cases.

 

These ISO XSD-schemes are usually quite good for validating malformed data. And to enforce a consistent format of data exchange (which is the entire point of xml)

You'd be correct that any further validation of what sort of data you want allowed would need to be internal.  (Unless you included some bounds of the date that you'd allow, but I'm not sure on the specifics of this one)