Complexity of date/time issues (was Re: DR 10-0001...)

[Chris Rae]

Hi Norbert - as you say below, there are two separate issues at play here. The removal of 8601 dates from transitional is intended to bring transitional back toward parity with ECMA-376 - a number of WG4 members believe that transitional should not itself have been extended at the BRM, as stated in DR 09-0275, and this work is being proposed in this vein.

The second issue is how time zones should be treated in spreadsheets. Although time zone support was seemingly introduced at the BRM with the adoption of ISO 8601 dates, it's been the feeling of some WG4 members that the ISO 8601 date support was not specific enough to allow implementers to interoperate in all cases. The support added at the BRM technically allowed anything that could be lexically represented in a format specified by ISO 8601 to exist in a spreadsheet cell - as well as dates and times, this encompasses dates with timezones, durations, recurring time periods and several other things that the standard gives too little information to allow implementers to utilise. As a result, WG4 began work on "profiling" ISO 8601 date support - this essentially meant cutting down the variants of ISO 8601 lexical formats to a manageable set which made sense in spreadsheet cells. Right now, that work incorporates a statement that all dates and times are stored in spreadsheet cells as local time, with no time zone component. This definitely goes against your wish that time zones be incorporated into SpreadsheetML and we'd be interested in your thoughts as to how time zones could successfully be dealt with in SpreadsheetML without the existence of a reference implementation. Will you be on Thursday's WG4 call? It would be great if we could put these two items on the agenda.

Chris

-----Original Message-----
From: Norbert Bollow [mailto:nb at bollow.ch] 
Sent: 01 May 2010 01:48
To: e-SC34-WG4 at ecma-international.org
Subject: Complexity of date/time issues (was Re: DR 10-0001...)

Chris Rae <Chris.Rae at microsoft.com> wrote:

> WG4 are currently working simultaneously on:
> 
> * Removing 8601 dates from transitional (DR 09-0275)
> * Removing the leap year bug from strict (DR 10-0001)
> * Profiling 8601 dates (project JTC 1.34.29500.04.02.00.01)
> 
> Unfortunately all of these involve complex edits made to the same 
> sections of text and (as Gareth's changes to the document on this 
> thread demonstrate) it is becoming difficult to track the work 
> independently and we're increasingly opening the risk of mistakes when 
> we eventually integrate these DRs into the standard. It's more than 
> just a different word here and there - for example, some of these 
> changes involve many edits to text which another change is removing 
> entirely.

Another complication to consider here is that "Removing 8601 dates from transitional" will re-open timezone-related concerns such as those raised by Switzerland back in 2007 during the DIS ballot. In particular, it has been the Swiss position that it must be possible to associate timezone information to spreadsheet date-time data, and that there must be support for correctly handling the transition to daylight-saving time and back. These issues were addressed to our satisfaction by the mandatory adoption of the ISO8601 format, and if we're now moving away from the ISO8601 format for documents of the Transitional conformance class, I would expect that Switzerland, and probably other countries too, would probably insist these concerns would have to be correctly addressed in some other way.

Greetings,
Norbert