wrote:
> Here's what I'm thinking:
>
> We have an abstract machine that does operations on dates. Dates, when
> stored, are stored as ISO 8601 strings. We also define explicit and
> implicit ways of converting numeric data into dates. The implict coercion
> method has one or more parameters, one of which is the date basis.
> ... I don't think
> we should care. What we really need to define is the type conversion.
>
> If we state it along those lines (conceptually -- obviously the text would
> need to be more fully articulated) would that do the job?
Well, they really ARE numbers. For example, ISNUMBER() must return
TRUE() for a date or datetime value. I know of no spreadsheet
applications that has a true separate date type; I believe all
applications simply use numbers, and whether or not it's a date or time
or datetime is simply a formatting property of a particular cell. ODF's
storing of the 'current cell value' as an ISO date is still very nice;
it partly isolates spreadsheets from some of the worst nastiness of
epoch values.
If describing the operations as a separate type would be the best way to
express what's required, then it might still be fine to word it as a
"separate" type, if worded carefully. Certainly there are a lot of
languages with such types which could be used as a model. Of course,
good wording is always the trick :-). Part of the reason the current
text is so awkward is because it's trying to work around the obvious
problem: Some applications (intentionally) calculate 1900's leap-year
incorrectly, while others do it correctly.
If the current text isn't as clear as it should be, then by all means,
please, propose an alternative!
--- David A. Wheeler
