My comments on DR 10-0001

Jesper Lund Stocholm jesper.stocholm at ciber.dk
Thu Apr 8 14:35:24 CEST 2010


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



More information about the sc34wg4 mailing list