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
well-defined.
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.
-Rob
