Long stupid debate on OOXML and the year 1900 (was: Ecma responses
to ISO)
Ben Scott
dragonhawk at gmail.com
Sun Mar 11 13:13:38 EDT 2007
On 3/9/07, Jon 'maddog' Hall <maddog at li.org> wrote:
> I thought you were "way smart enough" to guess why. It was to make a
> joke ...
Ah. Well. Obviously, I didn't "get it". Maybe the joke's been
made too often, and isn't funny anymore. Or maybe I like jokes, but
when they're used in place of of serious discussion, instead of along
with it, I get irritated. Meh.
>>> So anything else was and is a bug ...
>
> The use of two-digit years more or less a "programming standard" ...
Blah blah blah. It's still the exact same situation: A date-related
bug that was retcon'ed into a standard.
In the case of the C library, the intent was to have the library
routine return the last two digits of the year. It did that not to
save storage, but because *that's how people think*. Nobody thought
ahead to 2000 because that seemed a long way off. Later, when it was
realized that some software does indeed need to care about the
century, they decided to define the routine as returning the year
minus 1900. That kept compatibility with existing code.
Likewise, when Lotus was writing 1-2-3, nobody thought back to 1900
or ahead to 2000, because that seemed a long way off. So the original
implementation didn't do leap years correctly. Later, when it was
realized that some software does indeed care about 28 Feb 1900 through
1 Mar 1900, they decided to define the routine to be the number of
days since 1900 plus 1.
It actually sounds like OOXML isn't as bad as the C standard,
because at least OOXML gives you the *option* of not incorporating the
bug.
The rest of the examples are just that: Examples. They are given to
illustrate the point, not define it. I'm not interested in debating
the examples further.
>> Yet we don't throw this stuff out because, what-do-you-know,
>> compatibility with existing stuff is sometimes important.
>
> The big difference is that the Gregorian Calendar had been around a long
> time bu the time of the electronic spreadsheet ....
And the concept of a century wasn't around when they wrote Unix?
> So by the time that Lotus 1-2-3 (1983) or Microsoft Excel came out, date
> calculation was not a Phd research project.
So what? Coulda, shouda, woulda. The fact remains that the bug was
enshrined in a standard.
> If Lotus ... had fixed it in the beginning, this "option" to this standard
> would not even exist.
Right. If Lotus had fixed it, this "option" to this "standard"
would not even exist. But they didn't.
> But they decided not to.
The story goes that there were tons of customer spreadsheets in
existence by the time the bug was realized, and that fixing the bug
would break all those existing spreadsheets. When the number of days
since 1900 mattered, those spreadsheets already corrected for the
known error anyway. So compatibility was deemed more important than
strict correctness.
Not my call. Not even Microsoft's call. It's the de facto standard
that 1-2-3 created.
> Now we are encoding this mistake to be in a standard for the rest of
> time. People implementing to the "standard" will have to implement
> both, test both, make sure that both work, just because someone did not
> fix it when they should have.
Yup. And just last week, I had to add 1900 to tm_year for the
umpteenth million time. I even put in a comment:
$year += 1900; # stupid Y2K
Life sucks, don't it?
>> Of course, maybe that claim is wrong. Hence my desire for facts.
>> But it appears we're not interested in facts unless they reflect
>> poorly on Microsoft. Victory at any price, I guess.
>
> No, I am reflecting on a business practice that was followed for ...
What's your beef, here? That Microsoft is evil, or that the
standard is flawed? (Okay, I think I can assume the answer would be
"both".)
Yes, Microsoft is evil. Their code is full of bugs. They use their
monopoly power to shove their crap down our throats anyway. They
don't believe in standards. They're charging $4000 for a time zone
table. They suck.
But *what does that have to do with OOXML*?
Your very fine rant there has nothing to do with this proposed
"standard". It seems to manly be concerned with the fact that
Microsoft is evil. While OOXML is Microsoft's proposal, all that
means is that it should either (1) be rejected out-of-hand, since
they're evil or (2) gone over with a fine toothed comb. Since #1
isn't how the world works, that leaves #2.
Going over this proposed "standard" with a fine-toothed comb finds
lots of things. One of them is that there was a bug in Lotus 1-2-3
that's still being assumed today. There's an option to emulate that
bug.
One can argue that emulating an old bug is needless baggage in a new
standard like this. But one can also argue that there's a lot of old
spreadsheets out there, and auditing them all to find the ones that
assume this bug would be a lot of work, and that it's a lot easier to
just put in a compatibility mode. I don't know that there is any way
to determine which argument is more correct.
Also, there is lots of other crap in OOXML that is, in my opinion,
far worse, but that's not really part of this discussion.
>> I normally detest propaganda, even propaganda whose nominal cause I
>> agree with. I suffered a lapse of judgment in this situation. As a
>> result, it appears I'm once again being taught the lesson as to why I
>> detest propaganda.
>
> What propaganda may I ask?
Propaganda is information disseminated for the explicit purpose of
causing a particular conclusion to be released.
In this case, the conclusion would be "OOXML should be rejected,
because it forces people to include an extra day in their spreadsheet
calculations, and BTW, this is one more reason Microsoft is evil".
It seems possible that a more accurate depiction of the facts would
be that "OOXML includes a compatibility mode to support existing
spreadsheets that assume a bug that dates back to before Microsoft
even had a spreadsheet product".
> If Lotus-1-2-3, or Microsoft Excel or whoever had propagated this in the
> past had been FOSS ....
And if wishes were fishes, we'd have... one freaking huge pile of fish.
The fact of the matter is that Lotus *didn't* fix the bug, and we're
stuck with it now. Just like the fact that, in the year 2112, we're
still going to be adding 1900 to time_tm, even though people will
probably have long forgotten why.
-- Ben
More information about the gnhlug-discuss
mailing list