Iljitsch van Beijnum <iljitsch@xxxxxxxxx> wrote:
> Sorry for the complete change in subject, but I think it's important
> to avoid confusion here:
>
> On 1 dec 2007, at 12:22, Frank Ellermann wrote:
>
> > Disclaimer, I like Excel
> > on boxes where it's available, it's a nice product. But it's
> > not nice enough to say that 1900-02-29 was day 60 in year 0,
> > if that's what the 6000 ooXML pages say (I only looked at some
> > nits in the BSI Wiki, I never read any page of the huge draft).
>
> What are you trying to say here?
>
> There never was a februari 29 in 1900 so giving that non-existant day
> a number would be problematic. From your statement, I assume there is
> a standard that does this, but I'm not sure which one and why. Could
> you enlighten us?
I'm not sure how much enlightenment is possible with regard to such
a silly issue, but having participated in the discussion of this issue
in the concerned "standardization committee" of the Swiss Association
for Standardization, I'm able to provide a bit of background
information:
First of all, I wouldn't call the OOXML specification a "standard"
("Ecma-glorified documentation" would be a more fitting description of
what it really is, IMO), but it is true that the OOXML spec requires
the famous one-off bug in the "common day and time representation" for
weekdays and day numbers for all days before March 1, 1900 which can
be represented at all in that "common day and time representation"
(days before January 1, 1900 are not allowed at all).
The justification which Microsoft gives for this quirk is that they
don't want to fix this bug because they consider it unacceptable to
break "Excel" macros which rely on the buggy behavior.
Also, Microsoft points out that besides the "1900 base date system"
which has this bug, the OOXML spec provides an alternative, called
the "1904 base date system" which avoids the bug, at the cost of
disallowing all dates before January 1, 1904.
Of course, if the goal had been to produce a reasonable standard, they
could simply have re-used an existing standard date representation
format, or they could have defined a new one which is able to express
all valid dates of the Gregorian calendar without such a one-off bug,
and they could have introduced a "legacy behavior compatibility mode"
for macro execution which reproduces the buggy behavior.
The one-off bug in the first two months of the year 1900 may not be
a big problem for most of Microsoft's customers, but it becomes a
serious issue when someone who considers OOXML to be a standard wants
to represent earlier dates in a way which is compatible.
In the discussions in the Swiss Association for Standardization,
Microsoft expressed willingness to agree to a reasonable comprimise
regarding this point, namely to deprecate that "1900 date base system"
which has that bug, and to recommend for general use the modification
of the "1904 base date system" that is obtained from the system
described in the OOXML spec by dropping the restriction that the day
number must be positive.
By the way, there is another serious issue with OOXML's "common day
and time representation" format: Regardless of the base date, that
day and time representation is fundamentally broken on all days which
are 23 hours or 25 hours long rather than the usual 24 hours. (In
many countries that occurs twice per year, due to switching to DST or
back.) Regarding that issue Microsoft did not express any willingness
to compromise.
Shortly after the meeting in which these discussions were held, a very
large number of Microsoft "certified gold partners" joined that
"standardization committee", admittedly encouraged to do that by
Microsoft corporation, all of them voting for the viewpoint that the
OOXML spec is fine as-is for approval as an international standard,
without any need for discussion or fixing of the various technical and
other issues that had been raised about OOXML. So many of them joined
that they reached 3/4 majority, thereby rendering the previous
technical discussion essentially irrelevant.
Greetings,
Norbert.
--
Norbert Bollow <nb@xxxxxxxxx> 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
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf