Draft for review: ISO 8601 date work on IS 29500
Gareth_Horton at datawatch.com
Fri Jul 9 18:57:01 CEST 2010
This subject has been discussed ad nauseam and I see no reason to revisit it, unless you know of a reference implementation of spreadsheet software that supports timezones.
As far as I know, no spreadsheet software in existence supports time zones, nor have any seen fit to implement such support since their inception in 1979. Usually, in the software industry, features which are in very high user demand are implemented in under a 30 year timescale.
I can see that it may well be a useful feature, however, until an implementation exists, it would be extremely unwise to try and engineer such an implementation backwards from the file format level and force it upon implementers.
As v (Cell Value) is a string, you may of course store a string in any possible combination, including a string which represents a datetime with timezone.
Any application which wishes to write and read such strings in cell values is free to do so. However, in order to maintain any vestige of interoperability regarding date handling and date related functions, what they cannot do, is to expect other applications to treat that data as dates.
The whole point of this Amendment is to improve date interoperability, introducing an enormously complex featureset with no existing implementations at the file format level would certainly not help in this respect.
As you are well aware, issues of data quality and data integrity are *critical* in spreadsheets and I would not be involved in any activities that could jeopardise this.
Please do let me know about any spreadsheet implementations that support timezones, as we could consider starting a research project on how we might introduce timezone support.
I urge you to read David Wheeler's (OpenFormula TC) post on timezones in spreadsheets, as part of their work on OpenFormula (which does not support time zones):
"It's clear that, as part of the ISO process, somebody said "OOXML should support timezones", so somebody added some text about timezones. But that material is clearly incompatible with actual spreadsheets, and it's incompatible with other parts of the same spec :-(. Saying "timezones would be nice to have" must NOT translate into some random text that is unimplementable or is incompatible with existing spreadsheets... Please understand, I'm not against timezones. But since timezones have never been supported by spreadsheets, extreme caution is warranted. Unless there's an "obviously correct" solution for supporting timezones, that can also support existing spreadsheets, it's better to leave them out"
From: Norbert Bollow [mailto:nb at bollow.ch]
Sent: 09 July 2010 06:58
To: e-sc34-wg4 at ecma-international.org
Subject: Re: Draft for review: ISO 8601 date work on IS 29500
Chris Rae <Chris.Rae at microsoft.com> wrote:
> First off, our dateTime type is indeed a subset of xsd:dateTime, (it's
> basically xsd:dateTime without time zones).
Hi Chris and everyone,
I'm strongly in favor of using xsd:dateTime as-is, without restricting it.
What's the benefit of making OOXML an island where timezones cannot be expressed?
Essentially the entire rest of the XML world acknowledges the fact that timezones exist and are sometimes important.
Representative in matters of international standardization of the Swiss Open Systems User Group /ch/open - http://ch-open.ch
Owner/CEO, Adaptux GmbH - http://adaptux.com Coaching and Consulting in all areas of informatics management including Goal-Setting, Strategy Development, Procurement, Day-To-Day Operations, Software Asset Management, Risk Management, Benefit Orientation Management.
More information about the sc34wg4