My comments on DR 10-0001

[Jesper Lund Stocholm]

Hi Chris (and all),

Let me address some of the points you make.

First, let me emphasize a few things:

1. There is no such thing as a serial date in Part 1. I know that some
interprets the last paragraph in Part 1, section 18.17.4 as allowing
serial dates, but this paragraph (in my reading) deals exclusively with
guidance to strict consumers on how to interpret non-conforming
spreadsheets with serial dates.

2. Dates are persisted in strict documents (spreadsheets) as ISO-dates.
Not as serial dates but as ISO-dates! This effectively means that the
leap-year bug does not exist in S documents, since the date 1900-02-29
cannot be persisted in ISO-8601 format.

See below:

> -----Original Message-----
> From: Chris Rae [mailto:Chris.Rae at microsoft.com]
> Sent: 26. marts 2010 17:20
> To: 'SC 34 WG4'
> Subject: My comments on DR 10-0001
> 
> DR 10-0001: SML: Remove dateCompatibility attribute from strict
schemas
> and occurring places in Part 1
> 
> I am not in favour of this DR because of the difficulty it presents in
> migrating documents from transitional to strict.

Yes, we are aware of those difficulties.

> Because dates are
> treated as numbers at runtime by spreadsheet applications, it's
> impossible to tell whether a given cell truly contains a date.

No - in strict documents dates are not serial dates - they are persisted
in ISO-8601 format. There is no issue wrt figuring out if the cell
contains a date or not. The only time this would pose a difficulty would
be if someone created an strict spreadsheet with a serial date in it and
styling it using "the old transitional way". But that document would be
non-conforming since it would be in violation with the constraint that

"Each unique instant in SpreadsheetML time is stored as an ISO
8601-formatted string"

> All one
> can tell is whether a cell is *formatted* as a date. If I type
=TODAY()
> into a cell, for example, and then format it as a number, I will see
> "40263". Passing this value into date-related functions will produce
> valid values and reformatting the cell as a date format will show a
> date - as far as I (as the user) am concerned, the cell contains a
> date, but my app has no way to know that.

Yes - for transitional files.

> Removing the leap year bug from a workbook will cause any values
before
> 1st March 1900 to display differently - they will all move forward by
> one day. Additionally, several functions (DAY, MONTH, etc) will
produce
> different results. Any existing spreadsheet hand-crafted to "fix" the
> leap year bug will now start to produce incorrect results.

I dissagree. Dates in S files would not suddenly "move" - since they
would not be serial dates - they would be ISO-dates. They wouldn't even
move in existing transitional documents, because the attribute should
clearly stay in T and it has a default value of "true". The only case
this would be a problem would be when an application is trying to
convert a spreadsheet from S to T. If a vendor is not comfortable in
being able to convert a T spreadsheet to S, they should not do it. 

> I acknowledge that this is a small date range, but the impossibility
of
> mitigating risk to users' data will make it difficult for implementers
> to safely transition existing documents to strict, and as such I
oppose
> this DR.

This has not much to do with whether the date range is small or not.



// This has to do with an issue that in the opinion of Denmark is a
clear legacy-issue and which should stay that way. //



I realize that not being able to (re)use the leap year bug in S files
will make it impossible to convert certain documents, but that is really
a vendor issue. I also realize that vendors (exclusively) supporting the
leap-year-bug in their calculation engines will have to make
(substantial) modifications to it, but again - this is a vendor issue
and not a specification-issue.

The presence of the dateCompatibility attribute in S documents is in my
mind a clear self-contradiction in OOXML, because requiring saving dates
in ISO-8601 format clearly removes the leap-year-bug from S files (sine
the date 1900-02-29 cannot be saved in S spreadsheets). Having an
attribute requiring a consumer to somehow re-apply the leap-year-bug
based on a persistence format not supporting it really makes it
virtually impossible to implement OOXML S.


Jesper Lund Stocholm
ciber Danmark A/S