[Fwd: Ecma responses to ISO]

[Jon 'maddog' Hall]

On Fri, 2007-03-09 at 17:42 -0500, Ben Scott wrote:
> On 3/9/07, Jon 'maddog' Hall <maddog at li.org> wrote:
> >>   Anyone know what the facts are here?
> > >
> > 1900 was not a leap year....
> 
>   Now, I *know* you're way smart enough to understand what I was
> asking there, and "Was 1900 a leap year?" was obviously not it.

Yes, I understood that.

> I can only assume you're being obtuse on purpose.  Should I ask why, or
> should we just move on to the comparison-to-radical-groups phase of
> Degenerative Online Discussion Syndrome?

I thought you were "way smart enough" to guess why. It was to make a
joke, but since you didn't take it that way, let's move on to the real
fun....

> 
> > So anything else was and is a bug ...
> 
>   So is the C standard library's definition of "tm_year" to be the
> number of years since 1900 (a retcon to work around a Y2K bug that was
> written into the system from the beginning).

The use of two-digit years more or less a "programming standard" of a
lot of systems of time that Unix was invented (1969) typically caused by
short-sightedness in programming linked with very small and expensive
memories for computers.
One can argue that people should have been more foresighted, but when
memories cost 128,000 US dollars (and that was when a three-bedroom
house on an acre of land went for 29,000 dollars) for 65K bytes of RAM,
people took two bytes very seriously.

Most programs in those days seemed to have a three-to-five year lifetime
before a complete re-write was necessary and most programmers never
dreamed that their programs would still be used fifteen or twenty years
later when the issue started to appear.  Or one can argue that years
should always be represented by four digits, but then (as the song
says), "in the year 9999..."

In the case of Unix this was exacerbated by the fact that the Unix
system started when it did. Dennis and Ken chose a particular year to
start as "the beginning".  One can argue that they should have foreseen
the need for century roll-over and set the date originally to 1900, or
to the year zero, but of course one can remember that clock ticks of a
100 milliseconds can fill up even a 32-bit register fairly quickly, so
starting with year zero as "0" would cause (to people mostly doing
scientific/engineering programming) an extraordinarily large starting
point for practical calculations in what was basically a 16-bit machine
(the PDP-11) which did have a 32-bit
clock register (two word arithmetic).

But while the "retcon" was needed to fix these problems, it was not a
"bug", IMHO.  The software worked as advertised, and did not break any
existing standards.

> So is "creat()" (it should be spelled "create", regardless of what the PDP
> linker they were using could handle).

I will disagree with the above statement.  While in the English language
the concept that the routine "creat" does the function similar to what
the English term means to "create", and even that the name used to
describe the function is the word "create" itself, there is no
"standard" that says that the name of the function had to be spelled a
particular way.  It could have been called "foo".

This was not a bug.

>So is the fact that "gets()" has no facility to identify the size of the
>buffer it writes to.

While it might be desirable that "gets()" has the ability to identify
the size of the buffer it writes to, this too is not a standard, and
while you may argue it was a design flaw, the "gets()" routine performed
as advertised.

> So is about half of the X Window System.

Matter of debate. Now who is being obtuse?

> 
>   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 was typically
something learned in the eighth grade.  I remember writing a routine to
figure out dates as a college student in 1969 (way before Lotus
1-2-anything).  I did quite a study on it, and while I still have to go
back on my fingers and figure out slowly whether 1900 was or was not a
leap year, I would have taken the time and effort to get it right, and
would have fixed it if it was wrong.

I also remember a very famous memo sent out by Digital in the early days
of Digital's existence in response to a customers
Problem Report explaining to a customer that 1900 was not a leap year,
and going all the way back to before the Julian Calendar in its
explanation, ending in a rather graphic and profane illustration to the
customer of "see figure one".

So by the time that Lotus 1-2-3 (1983) or Microsoft Excel came out, date
calculation was not a Phd research project.  In fact, during the early
eighties, the beginnings of "Y2K" were beginning to rear their ugly head
in things like 30-year mortgage calculations and such.  Lotus should
have been more aware than ever of the issue.

If Lotus (or Microsoft or whoever created the problem) had fixed it in
the beginning, this "option" to this standard would not even exist.  But
they decided not to.

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.

People do not need a standard to allow a work-around to a bug.
They will continue to work around it whether or not the standard exists.
They need a standard to say "this is how it is supposed to work".
> 
> > ... because it was a stupid bug, the bug fix should be freely available.
> 
>   Well, again, reading the response that got posted to the list, the
> "bug compatibility" mode described is an optional mode, and the "fix",
> to use your term, is also defined in the proposed standard -- namely,
> not using said optional compatibility mode.
> 
> 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 many
years in production software.  The difference between "mission critical"
bugs and "annoyance" bugs.   Usually a call of the product manager,
since cost of distributing bug fixes was comparatively large in the old
days.  It meant tapes (and sometimes disk packs) going out to customers,
not bits going over the net.  But when the bug fix was a critical one we
bit the bullet and sent it out.  No "$4,000." charge.  I remember
as a product manager forcing the issue of creating a bug fix for Ultrix
to patch a system that we had retired, because people were still using
the system and we knew it.

Someone in the ancient past made a decision that fixing the
calendar bug was not important enough, or that it was better for the
end-user or macro-writer to create a work-around than to fix the bug.
Then, if or when the bug was fixed, the end users seemed to have thought
it was not worth it to go back and fix the code, but to continue using
the broken macros that propagated that bug.  And now, due to ECMA, this
bug will continue to be "supported" for all of time, not as a "bug", but
a feature.

If the standard did not support this "feature", then the person or
company running into it would be able to request a bug fix.  If the
standard "supports" this feature, then the manufacturer says, "Oh it is
part of the standard".
> 
>   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?  We have had a number of people step forward
on this list in the past couple of days, including yourself, talking
about the issues of trying to get ready for DST.  I actually feel sorry
for Microsoft in this case, since
it was not their idea to change daylight savings time.  It was
not really THEIR bug, but more a design flaw (sort of like the tm_year
could be considered a design flaw) to put it in so many places.  And
certainly I understand the issues of having to drop support on an
operating system or layered product because you, as a company, have
moved on. But I do consider some bugs, including the DST "bug" critical
enough to business that the money for the time and effort needed to fix
this problem should be paid for out of 10 seconds of MS sales, and not
have to put people through the wringer for $4K.

I also saw a "Standard" proposed that went on to propagate an ancient
wrong to all of time.  People who go to implement XML systems will have
to put in both "representations" of the Gregorian calendar.  IMHO it WAS
wrong, and it IS wrong.

If Lotus-1-2-3, or Microsoft Excel or whoever had propagated this in the
past had been FOSS, it would have been just as easy to correct the
ancient bug as it was to create the broken macro that fixed it.  And
there would be no "need" for this ECMA "fix".

In both of these cases I advanced no propaganda.  Just stone, cold fact.
> 
> -- Ben

Warmest regards,

md