Re: [office-formula] Conflict between Part 1 and Part 2

[robert_weir@us.ibm.com]

Patrick Durusau <patrick@durusau.net> wrote on 02/04/2010 03:08:22 PM:

> Greetings!
> 
> Just in case anyone is dodging the flood of JIRA comments, ;-), do take 
> note of Office-2343 on Date and DateTime that has uncovered an apparent 
> conflict between parts 1 and 2.
> 
> http://tools.oasis-open.org/issues/browse/OFFICE-2343
> 
> Briefly, part 1 sets a default of 1899-12-30 and part 2 says evaluators 
> "*shall* support all dates from 1904-01-01 through 9999-12-31 
> (inclusive), with correct calculations." (Emphasis added)
> 
> Looks like it leaves out the default set by part 1.
> 

I'd take the 1904-01-01 as a portability statement.  Some implementations 
support earlier dates, but all support dates of 1904-01-01 and later.


> Andreas has suggested additional setting information to process 1900 as 
> leap year expressions. (we currently lack a mechanism to signal that, we 

> simply say they exist).
> 

I think there are several parameters of the date system: 

1) origin/epoch, i.e., what is the zero date

2) What is the earliest date allowed, i.e., if negative dates are allowed, 
how far back can they go

3) If dates are allowed pre-Gregorian, what happens in that 
Julian./Gregorian transitional period, or do we just use proleptic 
Gregorian dates.


I think we want say the default behavior is Gregorian, with origin 
1899-12-31, with proleptic extensions if negative dates are supported back 
that far.  But the exact date range supported is implementation-defined.

We already have an attribute to specify a different origin.

If we had the 1900-leap year flag, how would implementations use it?  I 
imagine implementations that natively have that behavior would always 
write out documents with that attribute set to true.  Other applications 
processing the file would need to do what exactly?  It effects more than 
1900, right?  It effects all dates after February 28th 1900.  Or more 
properly, it effects the implicit conversion from number to date, the app 
would need to test whether the date is pre or post 2/28/1900.  If it is 
post, then the conversion adds the number to the origin date to determine 
the date.  If it is post 2/28/1900 then it adds one day to that date. This 
also trickles into any date interval calculations, such as YEARFRAC() and 
all financial calculations that depend on the number of days between two 
dates.  If the range intersects with February 28-March 1st 1900, then it 
needs to be treated as a special case.

The alternative would be to mandate Gregorian processing for 1900.  Then, 
implementations with that leap year bug would need to add logic when 
reading and writing ODF documents to write out correct dates, and numbers 
that are correct conversions from those dates.  The only value that could 
not be represented in ODF that way would be the non-existent *February 
29th, 1900.  But I think any use of that date in a spreadsheet would 
reflect a user error and it would be a good thing if the user was notified 
as to that error.

The way I look at it, from the implementation perspective, the complexity 
of accommodating the bug is roughly the same as correcting the bug.  And 
since there are more applications that do not have the bug than do have 
the bug, I'd favor mandating Gregorian calculations for 1900. 

-Rob