[OpenISO] Problems with the "combined date and time representation"

[Norbert Bollow]

Henrik Sundberg <storangen at gmail.com> wrote:

> I fully agree with the text, but shouldn't a heading for proposed
> solution be added?

Hmm... the deadline for submitting proposed solutions is long past.
(In fact, for each of the three issues discussed below, I've
submitted solution proposals through the ordinary channels of the
ISO/IEC process.  Whether that'll do some good, or merely contribute
to empowering MS in the area of "smoke screen" creation as you have
warned in your blog posting, that remains to be seen...)

The purpose of the present document is to assist national
bodies with making the decision whether they want to change
their vote regarding OOXML (e.g. from "APPROVE" to "DISAPPROVE"
or vice versa), as they can during the month after the BRM (which
ends on February 29).

In fact, given that Microsoft has already pushed out the
implementation of this badly designed format to a huge number of
customers who cannot be expected to upgrade their software anytime
soon, for many of the problems there probably is no possible way
anymore to really avoid the interoperability problems.  Declaring
the misfeatures "deprecated" is a IMO positive step, but clearly
very far from truly solving the interoperability problems.

I'm drawing the conclusion from our discussion that a major goal of
the "problem report" document should be to dispel the illusion that
the problems with OOXML are easily solved.

I've updated the draft text about the three issues concerning the
"combined time and date representation" accordingly, see below.


--snip---------------------------------------------------------------

Timezone information for spreadsheet date-and-time data
=======================================================

Part 4, 3.17.4.2 and 3.17.6.7

Problem description:
~~~~~~~~~~~~~~~~~~~~

The numeric data format for date information in OOXML's spreadsheet
data format, the so-called "combined date and time representation",
has undefined semantics with regard to what timezone the date-and-time
data refers to.

Expected impact:
~~~~~~~~~~~~~~~~

Serious interoperability problems are to be expected whenever
date-and-time data is communicated timezone boundaries.

In the internet age, as more and more business processes are
coordinated and integrated internationally, it is clearly a
requirement that information must remain valid when it is
communicated across timezone boundaries.

Even if this issue is fixed in the specification, the
interoperability problems can be expected to persist for a long
time, because software implementing the inadequate version of the
data format has already been distributed to a huge number of end
users who will not update their software again anytime soon.



The switch to daylight-saving time and back
===========================================

Part 4, 3.17.4.3

Problem description:
~~~~~~~~~~~~~~~~~~~~

The numeric data format for date information in OOXML's spreadsheet
data format, the so-called "combined date and time representation",
represents times as fractional days, with the assumption that each
day has 24 hours.

Expected impact:
~~~~~~~~~~~~~~~~

Serious interoperability problems are to be expected with regard to
time data concerning days on which the switch to daylight-saving time
or back occurs.

The interoperability problem consists in the introduction of errors
of up to one hour for each affected time value, and it is particularly
problematic because the issue can easily be overlooked during testing.

Even if this issue is fixed in the specification, the
interoperability problems can be expected to persist for a long
time, because software implementing the inadequate version of the
data format has already been distributed to a huge number of end
users who will not update their software again anytime soon.



Dates before March 1, 1900
==========================

Part 3, 3.16.9
Part 4, 3.17.4.1

Problem description:
~~~~~~~~~~~~~~~~~~~~

The numeric data format for date information in OOXML's spreadsheet
data format, the so-called "combined date and time representation",
does not allow to correctly represent dates before March 1, 1900.
(Dates before January 1, 1900 cannot be preseneted at all.  Dates
from January 1, 1900 until February 28, 1900 are affected by the
so-called "leap year bug" which consists in the "combined date and
time representation" assigning a day number to the non-exiting day
"February 29, 1900" even though the year 1900 was not a leap year.
In addition, the draft standard specifies the following behavior
for the WEEKDAY function: "for dates between January 1 and February
28, WEEKDAY shall return a value for the day immediately prior to the
correct day".)

Expected impact:
~~~~~~~~~~~~~~~~

Serious interoperability problems are to be expected whenever
information about dates before March 1, 1900 is exchanged by different
programs.

Historical studies often consider dates before 1900.  Also, there are
people alive today who were born before 1900.  

Even if this issue is fixed in the specification, the
interoperability problems can be expected to persist for a long
time, because software implementing the inadequate version of the
data format has already been distributed to a huge number of end
users who will not update their software again anytime soon.

--snap---------------------------------------------------------------


Greetings,
Norbert.


-- 
Norbert Bollow <nb at bollow.ch>                      http://Norbert.ch
President of the Swiss Internet User Group SIUG    http://SIUG.ch
Working on establishing a non-corrupt and
truly /open/ international standards organization  http://OpenISO.org