OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


On Thu, 2010-02-04 at 13:39 -0700, robert_weir@us.ibm.com wrote:
> Patrick Durusau <patrick@durusau.net> wrote on 02/04/2010 03:08:22 PM:
> 

> If we had the 1900-leap year flag, how would implementations use it?

How would applications use the null-date?

If an application encountered a file created ona program with different
settings, at least it could warn the user that time calculations may be
affected.



>   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. 

Perhaps you could elaborate on how you determined how many applications
have a skip and how many do not. I could easily claim that more existing
spreadsheet files have dates stored as serial numbers with the skip than
there are those that do not have the skip.

Andreas
  




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]