Re: [office] Date and Timezone: draft text

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

> > For reference, here is how OOXML defines it: 
...
> Given that a date-time has at least 25 different representations (and
> likely many more), the statement "Functions that care only about the
> time shall ignore any date information that is provided" means that
> those functions would not  well defined.
> 
> How is this ever supposed to make sense?

It doesn't, and it can't.

This is actually the problem I'm trying to _avoid_.
It's clear that, as part of the ISO process, somebody said
"OOXML should support timezones", so somebody added some text about
timezones.  But that material is clearly incompatible with actual spreadsheets,
and it's incompatible with other parts of the same spec :-(.
Saying "timezones would be nice to have" must NOT
translate into some random text that is unimplementable or is
incompatible with existing spreadsheets.

I'm sure that what they meant was "if you only need time-of-day,
use X-INT(X); if you only need the day, use INT(X)."

Please understand, I'm not against timezones.  But since timezones
have never been supported by spreadsheets, extreme caution is warranted.
Unless there's an "obviously correct" solution for supporting timezones,
that can also support existing spreadsheets,
it's better to leave them out in this version.

BTW, _not_ all timezones only increment the "hour" value; some
have different values of "minutes".  Kabul, Afghanistan, is
UTC/GMT +4:30 hours. Katmandu, Nepal, is UTC/GMT +5:45 hours.
And that's only an instantaneous timezone; daylight savings time
creates MANY more complications.

You CANNOT simply store
everything as UTC and then do simple timezone corrections, while
having existing spreadsheets actually work correctly.
To store everything as UTC (as Unix and Linux systems do) requires
sophisticated corrections for daylight savings time (which vary depending
on geographical locations and the whims of legislatures).
A Unix/Linux system can do this, and in fact it's a remarkably elegant
solution for their time systems.  However, this works because these
systems _DO_ have information on which timezone is selected.
This information that is not available in a numbers-only encoding
(which is what a spreadsheet has).  What's more existing spreadsheets
do NOT expect to deal with this.

There may be an elegant way to deal with timezones.  But such
an elegant way must be defined in great detail, support existing
documents, and be "obviously right".  Otherwise, let's not bother.
There's no point in specifying a complicated system that gets it wrong.

BTW, I used to lead work on doing time-related standards.

--- David A. Wheeler