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] serial number? Don't we mean serial date?

I think we have four choices here:

1) State that Number<-->Date conversions are implementation-defined and 
non-portable, similar to how Number<-->Character conversions via CHAR() 
are in general implementation-defined, or string<-->number conversions. 

2) Same as #1 but define the semantics of a small number of specific 
calculations, such as:

a) Date + Number
b) Date - Number
c) Date - Date
d) INT(Date)
3) Date - INT(Date)

Note that this is similar to how pointer arithmetic is defined in C/C++. 
Some operations on a point are well-defined while others are not.

3) Mandate a canonical conversion between Numbers and Dates, i.e., a 
single origin and a single treatment of leap years.  I doubt we'd get 
consensus on this, but if we did then even the SIN() of a date would be 

4) Set a default canonical conversion between Numbers and Dates, i.e., 
base 1900, with correct Gregorian leap year calculations, but allow this 
to be overridden by sheet-level attributes in Part 1 that allow an 
implementation to set a different date original, and a leap year 
compatibility flag.  That way, implementation can continue doing what they 
do today, but declare their behavior via these attributes, and those 
implementations that wish to adapt can do so.


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