Well we can go either way with that. The ISO 8601 stuff I read seemed to be biased toward using Z, in that they mention it first, and then later also mention the +00:00 convention. Note that -00:00 is not allowed (though may in fact occur in practice quite a bit) I could certainly be convinced that it should be +00:00 instead. On Tue, Mar 19, 2013 at 1:07 PM, Steve Hanson wrote:

One question - would a literal time zone of "+00:00" return "Z" or "+00:00" ?

Regards

Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, *OGF DFDL Working Group* http://www.ogf.org/dfdl/ IBM SWG, Hursley, UK* **smh@uk.ibm.com* tel:+44-1962-815848

From: Mike Beckerle To: dfdl-wg@ogf.org, Date: 19/03/2013 15:57 Subject: Re: [DFDL-WG] Action 206 - proposed timezone-from-dateTime function - update Sent by: dfdl-wg-bounces@ogf.org ------------------------------

Revised Proposal (based on feedback and Workgroup call on 2013-03-19)

The following functions are added to the table in Section 23.5.3

dfdl:timeZoneFromDateTime($arg as xs:dateTime?) as xs:string? dfdl:timeZoneFromDate($arg as xs:date?) as xs:string? dfdl:timeZoneFromTime($arg as xs:time?) as xs:string?

Summary: Returns the timezone component of $arg if any. If $arg has a timezone component, then the result is a string in the format of an ISO Time zone designator. Interpreted as an offset from UTC, its value may range from +14:00 to -14:00 hours, both inclusive. The UTC time zone is represented as "Z".

If the $arg has no timezone component, then ""(empty string) is returned.

*Examples*

- dfdl:timeZoneFromDateTime(xs:dateTime("1999-05-31T13:20:00-05:00"))returns the xs:string value "-05:00". - dfdl:timeZoneFromDateTime(xs:dateTime("2000-06-12T13:20:00Z"))returns the xs:string value "Z". - dfdl:timeZoneFromDateTime(xs:dateTime("2004-08-27T00:00:00"))returns the empty string "".

On Tue, Mar 19, 2013 at 6:23 AM, Steve Hanson <*smh@uk.ibm.com*> wrote: Also noticed that in section 23.5.2.4 we do not state what the type of the return value is from the various date/time functions. They are all xs:integer except for the 'seconds' functions which return xs:decimal as they include any fractional seconds.

Suggest a sweep through all the other functions to check the return type is either stated or obvious.

Regards

Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, *OGF DFDL Working Group* http://www.ogf.org/dfdl/ IBM SWG, Hursley, UK* **smh@uk.ibm.com* tel:*+44-1962-815848* <%2B44-1962-815848>

From: Steve Hanson/UK/IBM To: Mike Beckerle <*mbeckerle.dfdl@gmail.com*>,

Cc: *dfdl-wg@ogf.org* , *dfdl-wg-bounces@ogf.org* Date: 19/03/2013 08:55 Subject: Re: [DFDL-WG] Action 206 - proposed timezone-from-dateTime function ------------------------------

Mike

This function may be used anywhere, and not just in the context of an element of calendar type. You therefore can't use the value of dfdl:calendarTimeZone. You should just return empty string if there is no timezone component.

We also need 3 variations of the function, like XPath 2.0:

dfdl:timeZoneFromDateTime($arg as xs:dateTime?) as xs:string? dfdl:timeZoneFromDate($arg as xs:date?) as xs:string? dfdl:timeZoneFromTime($arg as xs:time?) as xs:string?

Regards

Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, *OGF DFDL Working Group* http://www.ogf.org/dfdl/ IBM SWG, Hursley, UK* **smh@uk.ibm.com* tel:*+44-1962-815848* <%2B44-1962-815848>

From: Mike Beckerle <*mbeckerle.dfdl@gmail.com*

...

To: *dfdl-wg@ogf.org* , Date: 18/03/2013 18:29 Subject: [DFDL-WG] Action 206 - proposed timezone-from-dateTime function Sent by: *dfdl-wg-bounces@ogf.org* ------------------------------

I examined use of ISO durations, but that introduces a bunch of unnecessary complexity for implementors. I decided to propose instead use of an ISO 8601Time zone designator as an xs:string.

Proposed:

dfdl:timeZoneFromDateTime($arg as xs:dateTime?) as xs:string? Summary: Returns the timezone component of $arg if any. If $arg has a timezone component, then the result is a string in the format of an ISO Time zone designator. Interpreted as an offset from UTC, its value may range from +14:00 to -14:00 hours, both inclusive. UTC is represented as "Z".

If the $arg has no timezone component, then the value of the dfdl:calendarTimeZone property expressed as an ISO 8601 Time zone designator is returned, or ""(empty string) is returned if the dfdl:calendarTimeZone property is ""(empty string).

*Examples*

- dfdl:timeZoneFromDateTime(xs:dateTime("1999-05-31T13:20:00-05:00"))returns the xs:string value "-05:00". - dfdl:timeZoneFromDateTime(xs:dateTime("2000-06-12T13:20:00Z"))returns the xs:string value "Z". - dfdl:timeZoneFromDateTime(xs:dateTime("2004-08-27T00:00:00")) with dfdl:calendarTimeZone='America/New_York' returns the xs:string "-05:00".

---------- Forwarded message ---------- From: *Mike Beckerle* <*mbeckerle.dfdl@gmail.com*

...

Date: Tue, Jan 29, 2013 at 9:05 AM Subject: Re: clarification needed: datetime and time To: *dfdl-wg@ogf.org*

I also believe this means we are missing this function:

fn:timezone-from-dateTime($arg as xs:dateTime?) as xs:dayTimeDuration?

However, we don't have this result type dayTimeDuration, so rather than add that type, which is a structured thing like: PnDTnHnMnS, we should say it matches the iso 8601 time zone suffix on an iso datetime. So "Z" or "-05:00" etc.

Since it is not exactly the existing Xpath function, perhaps this function should not have this name or not be in the fn namespace. Come to think of it. I don't think we ever say exactly what the fn: prefix is bound to in DFDL.

On Tue, Jan 29, 2013 at 8:55 AM, Mike Beckerle <*mbeckerle.dfdl@gmail.com*> wrote: In the below. Should xs:datetime have trailing timezone as well? Right now it has no tz component.

Seems to me it should to match iso 8601 format which is what XSD uses.

Also, I believe we now think ZZZ is not the right behavior, and seems to be deprecated in ICU. The right thing is ZZZZZ. calendarPatternKind Enum

Valid values ‘explicit’, ‘implicit’

‘explicit’ means the pattern is given by dfdl:calendarPattern,

‘implicit’ means the pattern is derived from the XML schema date/time type.

*Logical Type * *Default Pattern* xs:date yyyy-MM-dd xs:dateTime yyyy-MM-dd'T'HH:mm:ss xs:time HH:mm:ssZZZ

Annotation: dfdl:element, dfdl:simpleType

-- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | * www.tresys.com* http://www.tresys.com/

-- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | * www.tresys.com* http://www.tresys.com/

-- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | * www.tresys.com* http://www.tresys.com/ -- dfdl-wg mailing list *dfdl-wg@ogf.org* *https://www.ogf.org/mailman/listinfo/dfdl-wg*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

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

-- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | * www.tresys.com* http://www.tresys.com/ -- dfdl-wg mailing list dfdl-wg@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

-- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com