My comments on DR 10-0001

[Shawn Villaron]

We should really just chat about this on the conference call ... 

-----Original Message-----
From: Jesper Lund Stocholm [mailto:jesper.stocholm at ciber.dk] 
Sent: Thursday, April 08, 2010 5:35 AM
To: MURATA Makoto (FAMILY Given); e-SC34-WG4 at ecma-international.org
Subject: RE: My comments on DR 10-0001

Hello Murata-san

> -----Original Message-----
> From: MURATA Makoto (FAMILY Given) [mailto:eb2m-mrt at asahi-net.or.jp]
> Sent: 8. april 2010 14:10
> To: e-SC34-WG4 at ecma-international.org
> Subject: Re: My comments on DR 10-0001
> 
> Jesper,
> 
> It appears to me that Chris is concerned about not changing the 
> semantics of formulas (e.g.,  "1900-02-28" + 2 = "1900-03-01") and 
> that you are concerned about disallowing "1900-02-29" as an ISO8601 
> cell value.

Well, it is not just "me" - it is the Danish national body - or mirror committee to SC34, that is.

We are concerned with the attribute dateCompatibility because it is the entry-point for the dateCompatibility data bases. These enable the leap-year-bug and should be removed from Part 1 - as per the Danish DR.

The issue is exactly what you outline above. 1900-02-28 + 2 is not 1900-03-01. It is 1900-03-02 . Removing the leap-year-bug from Part 1 will exactly change how formulas work - and the consequences for existing implementations with exclusive support for leap year bug might be high. But I do note that somehow the good guys from OOo have managed to get it to work in OpenFormula. That might be the reason for Chris'
worries (but I will not speculate any further on that). There is absolutely no need for support of the leap-year-bug besides legacy documents and existing implementations supporting either the binary document formats or T documents. Thus we should not support it in S since it defeats the purpose of S - namely to move past the legacy features.

I like the idea that Rick proposes because of these points:

1. It will clearly state that applications can do whatever they want (but, they of course can do this regardless of what we choose to do in
WG4)
2. It will send a signal to implementers that other implementers might treat specific dates as an error condition 3. Applications/documents with these dates will never, never, never be conformant


> Can we make both of you happy?  For example, is it possible to keep 
> the dateCompatibility attribute while explicitly disallowing  
> "1900-02-29" as an ISO8601 cell value?

The string 1900-02-29 is not a valid ISO-8601 value as it is, so I cannot see what that would help. The idea is to remove leap-year bug support from S.

We are of course interested in hearing what other NBs in WG4 think of our proposal.

Jesper Lund Stocholm
ciber Danmark A/S