[DFDL-WG] More Date/Time/DateTime Clarifications

[Steve Hanson]

Steve

1) Infoset output for calendar types:

The infoset output for all simple types is given in section 4.1.2 in the 
description of the [dataValue] member. It just says it is a value in the 
value space of the simple type as defined by the XML Schema 1.0 spec. 
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html

Your description looks correct. 

2) Implicit calendar patterns.

The point of calendarPattern 'implicit' is to provide a format that has a 
good chance of being applicable to real-world formats.  Leaving timezone 
out of the implicit pattern for xs:date makes sense, as although XSD 
allows it, very few date-only formats will carry a timezone. Leaving 
timezone out of the implicit pattern for xs:dateTime was a judgement call 
that could have gone either way. Given that the modeler always has the 
option of using an explicit pattern, and IBM's implementation is already 
in the field, I am happy to stay with the specification as it stands.

It sounds like the IBM tests are not correct in providing -08:00 in the 
data, they should be providing -0800. For some reason both formats are 
being accepted by IBM DFDL when ZZZ is used. I suspect this is ICU 
behaviour because we just call ICU with the pattern. I'll need to look 
into this further. We have an open ICU ticket #472 which is the subject of 
an open DFDL WG action to clarify leniency when parsing, but it does not 
list any leniency around Z handling.

Errata 2.127 was recently taken to change the implicit pattern for xs:date 
to use single Z instead of ZZZ, to match ICU preferred behaviour for the Z 
symbol. 

There are several other errata that affect calendar processing, so please 
refer to the errata document on Redmine @ 
http://redmine.ogf.org/dmsf/dfdl-wg?folder_id=5485. 

Also note that the x and X symbols are not supported by the DFDL 1.0 
specification as it currently stands.

HTH
Regards

Steve Hanson
Architect, IBM Data Format Description Language (DFDL)
Co-Chair, OGF DFDL Working Group
IBM SWG, Hursley, UK
smh at uk.ibm.com
tel:+44-1962-815848



From:   Tim Kimber/UK/IBM at IBMGB
To:     Steve Lawrence <slawrence at tresys.com>, 
Cc:     DFDL-WG <dfdl-wg at ogf.org>, dfdl-wg-bounces at ogf.org
Date:   15/04/2013 09:42
Subject:        Re: [DFDL-WG] More Date/Time/DateTime Clarifications
Sent by:        dfdl-wg-bounces at ogf.org



In XML Schema, all of the calendar types have a timezone - ncluding 
xs:date. I don't know why the specification omits the time zone for 
xs:date and xs:dateTime - I think they should both include a time zone 
unless there is a good reason not to. 

regards,

Tim Kimber, DFDL Team,
Hursley, UK
Internet:  kimbert at uk.ibm.com
Tel. 01962-816742 
Internal tel. 37246742




From:        Steve Lawrence <slawrence at tresys.com> 
To:        DFDL-WG <dfdl-wg at ogf.org>, 
Date:        12/04/2013 21:08 
Subject:        [DFDL-WG] More Date/Time/DateTime Clarifications 
Sent by:        dfdl-wg-bounces at ogf.org 



We need a couple more clarifications on implementing date/time/dateTime 
in Daffodil.

1) What is the expected infoset output? The spec seems to be silent on 
this issue. Based on some tests we received from IBM, it looks like this 
makes sense:

xs:date     = uuuu-MM-ddxxx
xs:time     = HH:mm:ss.SSSSSSxxx
xs:dateTime = uuuu-MM-dd'T'HH:mm:ss.SSSSSSxxx

Points of interest:
- uuuu instead of yyyy. The u allows for negative years, which is needed 
to represent BC dates
- There are 6 significant figures for fractional seconds
- Timezone is represented as xxx, since UTC is represented as +00:00 
instead of 'Z' in the IBM tests we have

Does this seem correct?


2) We would like some confirmation on the patterns for 
calendarPatternKind="implicit"?

The current spec has:

xs:date     = yyyy-MM-dd
xs:time     = HH:mm:ssZZZ
xs:dateTime = yyyy-MM-dd'T'HH:mm:ss

The IBM tests we have match these patterns except for the timezone 
pattern for xs:time. The ZZZ pattern matches -0800, however, the IBM 
test we have parse -08:00. This could be represented with a few 
different patterns (e.g. ZZZZZ, XXX, xxx, xxxxx). We're unsure if the 
IBM tests are incorrect of if the spec needs to be updated.

It also seems odd to me that the xs:time pattern has a timezone whereas 
dateTime does not. I'm not arguing it's wrong, just that it's not 
intuitive to me.


Note that we don't have IBM's tool set up yet, so we can't verify if the 
tests we have actually represent IBM behavior.

Thanks,
- Steve
--
 dfdl-wg mailing list
 dfdl-wg at ogf.org
 https://www.ogf.org/mailman/listinfo/dfdl-wg



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
--
  dfdl-wg mailing list
  dfdl-wg at ogf.org
  https://www.ogf.org/mailman/listinfo/dfdl-wg

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20130415/45e75682/attachment.html>