Re: [office] Date and Timezone: draft text

["David A. Wheeler" <dwheeler@dwheeler.com>]

> So who makes the first move to improve things?
> Wait for Excel?

No, nor has anyone claimed that.  All that's needed is
that SOMEONE demonstrate a reference model.

ANYONE can take an existing open source software
implementation, improve on it, and demonstrate that the
approach works.  It need not be an "official" release by
the project, though of course that would add weight.
If there's a demonstrated way to add that functionality,
and it gains rough consensus, then of course it's in
and I'd be delighted.

But humility in standards development is _critical_.
There is a very, very long list of "standards" that failed
because the committee wrote a standard or added an
"obvious little extension" in it, and THEN (after ratification)
someone tried to implement it.  The universal result has been that it
couldn't be implemented, or at least not in a way anyone
wanted.  Standards co-developed with
implementations is, in my view, the best approach.

At the least, no specification should be
accepted until there is at least one demonstration of
its effectiveness (e.g., a reference implementation),
and we are trying to wrap up OpenFormula 1.0.

I know timezones look easy, but adding this capability
is not as trivial as it appears.
The date and datetime representations of spreadsheets,
which users have found adequate for decades, do not
easily support them.  Numbers don't include a time zone.
Adding a mechanism that is unimplementable,
or makes it impossible to exchange existing documents, is unacceptable.

I'm not saying "timezones never go in".  But we're trying to
wrap up a spec that enables exchange of _existing_ documents,
none of which have timezones.  Let's get some experimentation/
reference model work going, and once a working solution
has achieved rough consensus, let's get that added to the NEXT
release of OpenFormula.

"Rough consensus and running code" is still the best way
to achieve useful standards; just compare OSI vs. TCP/IP.

--- David A. Wheeler