[DFDL-WG] Fw: DFDL WG action 153 : dfdl:calendarTimezone

[Steve Hanson]

The DFDL-WG call today agreed with the proposal below, with one change - 
if calendarTimeZone is a UTC offset then dfdl:calendarObserveDST is 
ignored, it is not an error.

Regards

Steve Hanson
Architect, Data Format Description Language (DFDL)
Co-Chair, OGF DFDL Working Group
IBM SWG, Hursley, UK
smh at uk.ibm.com
tel:+44-1962-815848
----- Forwarded by Steve Hanson/UK/IBM on 17/01/2012 19:07 -----

From:   Steve Hanson/UK/IBM
To:     dfdl-wg at ogf.org
Date:   13/01/2012 11:37
Subject:        DFDL WG action 153 : dfdl:calendarTimezone 


Minutes from DFDL WG call from last year:

  13.11. The DFDL property combination of dfdl:calendarTimezone and 
dfdl:calendarObserveDST 
  is insufficient as it does not cater for different start dates for DST. 
To achieve this we would have to
  relax dfdl:calendarTimeZone rules and allow it to take other formats, 
such as: 
  a) Olson format (eg, "Europe/Paris")
  b) Unicode short time zone IDs as per (Unicode Locale Data Markup 
Language ) spec (eg, "frpar")
  The list of TZs for b) is here: 
http://lawiki.org/extensions/core/common/bcp47/timezone.xml
   Note there a special value for 'unknown' - "unk"  or "Etc/Unknown" - 
prefer to empty string?
   Agreed in principle,  raised action 153 to decide on the extended 
format to use.
   Noted that calendarObserveDST would still be honoured.for UTC values.

Action 153 proposal

Allow dfdl:calendarTimezone to be either UTC offset format or Olson 
format, as per option (a) above. Olson is the most  widely-used naming 
convention for time zones. Option (b) above refers to 5 character UN 
LOCODE codes (where possible) which identify locations and map to Olson 
time zones. However they are not well known and therefore less usable.

For representing 'not specified' time zone stick with the current errata 
(2.50) and use empty string. It seems more obvious than "Etc/Unknown" 
which is not defined in the Olson database, so would have to be handled as 
a special case.

When unparsing and dfdl:calendarPattern contains a formatting symbol for 
time zone (zzz, Z, VVVV etc) and the infoset value does not contain a time 
zone, it is a processing error. This matches the behaviour on parsing when 
the data does not contain a time zone but the pattern does. Spec should be 
clear on this.

When dfdl:calendarObserveDST is set to 'yes', it only makes sense if dfdl:
calendarTimeZone is an Olson time zone. If it is a UTC offset then it 
should be a schema definition error if dfdl:calendarObserveDST is 'yes'. 

Regards

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






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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20120117/fa926ff3/attachment-0001.html>