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

[Henrik Sundberg]

2007/12/31, Norbert Bollow <nb at bollow.ch>:
> 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.

Thanks for the thorough explanation.
I fully agree with you. Adding a solution heading would clutter the
document and not enhance it for what it it is intended.

> 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
> _______________________________________________
> Discuss mailing list
> Discuss at openiso.org
> http://openiso.org/mailman/listinfo/discuss
>