Y2K Issues

Y2K Issues

[John J Cupak Jr]

[-- Attachment #1: Type: text/plain, Size: 480 bytes --]

Greetings!

I hope this question has not been posted yet. If so, I missed it even
though I looked in Deja News.

What is the effect of the Y2K problem on date calculations in Ada (both
83 and 95).

If this is a compiler vendor issue, what compilers have "certified"
their date calculations Y2K correct?

I also note that the Ada 95 LRM (RM96;6.0) Ada.Calendar package defines
the Year_Number as range 1901..2099. What happens in 2099? The world
ends?

Thanks,
John Cupak
Raytheon

[-- Attachment #2: Card for John J Cupak Jr --]
[-- Type: text/x-vcard, Size: 428 bytes --]

begin:          vcard
fn:             John J Cupak Jr
n:              Cupak Jr;John J
org:            Raytheon Systems Company
adr:            50 Apple Hill Road;;T3MN35;Tewksbury;MA;01876;USA
email;internet: John_J_Cupak@res.raytheon.com
title:          Software Engineering Instructor
tel;work:       978.858.1222
tel;fax:        978.858.4336
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard

Re: Y2K Issues

[Niklas Holsti]

John J Cupak Jr wrote:
> 
> Greetings!
> 
> I hope this question has not been posted yet. If so, I missed it even
> though I looked in Deja News.
> 
> What is the effect of the Y2K problem on date calculations in Ada (both
> 83 and 95).
> 
> If this is a compiler vendor issue, what compilers have "certified"
> their date calculations Y2K correct?

At least the TLD Ada 83 cross-compiler from Sun Solaris to
MIL-STD-1750A. TLD states that this compiler, the code it generates
and the RTS work correctly across Y2K. I have used this compiler
in the ENVISAT project for the European Space Agency. ENVISAT
launch date was originally late 1999, I believe it has now moved
to the following year...

I would expect most Ada compilers and RTSs to be Y2K-compliant, in
part because the problem is brought out by the Ada.Calendar type
declaration you quoted.

Niklas Holsti

Re: Y2K Issues

[dewar]

In article <362B53A3.64E266AB@res.raytheon.com>,
  John J Cupak Jr <John_J_Cupak@res.raytheon.com> wrote:

> If this is a compiler vendor issue, what compilers have "certified"
> their date calculations Y2K correct?

GNAT Professional is certified to be Y2K compliant, and I would assume that
any other vendor of a commercial Ada product would at this stage be in a
position to certify Y2K compliance (most customers require that these days!)

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Y2K Issues

[Tucker Taft]

John J Cupak Jr (John_J_Cupak@res.raytheon.com) wrote:

: ...
: I hope this question has not been posted yet. If so, I missed it even
: though I looked in Deja News.

: What is the effect of the Y2K problem on date calculations in Ada (both
: 83 and 95).

: If this is a compiler vendor issue, what compilers have "certified"
: their date calculations Y2K correct?

It is certainly compiler-specific, but from a language point of view,
because Time is a private type, it less likely that there will
be a year 2000 problem.   If there is one, it is more often in
the reliance on some non-Y2K-compliant system call.  E.g., in the
IBM MVS world, the "old" MVS system call only gave back a 2-digit year.
The typical MVS Ada compiler (of which there aren't many!) probably 
just added 1900 to that to produce the year.  Such a compiler
would have to be fixed to use the "new" MVS system call which returns
more digits.

Chances are most Unix-hosted Ada compilers have a Y2038 problem (when
the Unix 32-bit time goes negative).

: I also note that the Ada 95 LRM (RM96;6.0) Ada.Calendar package defines
: the Year_Number as range 1901..2099. What happens in 2099? The world
: ends?

There is admittedly a "Y2.1K" problem in Ada, but it is pretty benign, because
it is so straightforward to extend the definition of Calendar.Year_Number
to be 1901..2999 (or more).  No code outside of Calendar would have to
change.

I presume the reason for the original range was to minimize the amount
of code inside Calendar which needed to be devoted to leap year calculations.  
1901..2099 is the longest consecutive interval which includes today for 
which the simple rule that every 4 years is a leap year applies.  Neither 1900
nor 2100 are leap years, due to the second order correction in the
leap year formula.

We saw no reason to change the Year_Number range during the
Ada 9X revision.  We figured we wanted to leave something to the
Ada 205X revision ;-).

: Thanks,
: John Cupak
: Raytheon

-Tucker Taft  stt@inmet.com

Re: Y2K Issues

[Joe Gwinn]

In article <F1376o.Mq9.0.-s@inmet.camb.inmet.com>,
stt@houdini.camb.inmet.com (Tucker Taft) wrote:

> Chances are most Unix-hosted Ada compilers have a Y2038 problem (when
> the Unix 32-bit time goes negative).
> 
> : I also note that the Ada 95 LRM (RM96;6.0) Ada.Calendar package defines
> : the Year_Number as range 1901..2099. What happens in 2099? The world
> : ends?
> 
> There is admittedly a "Y2.1K" problem in Ada, but it is pretty benign, because
> it is so straightforward to extend the definition of Calendar.Year_Number
> to be 1901..2999 (or more).  No code outside of Calendar would have to
> change.

UNIX/POSIX time rolls over in 2100 as well.  This is the same problem as
the 2038 problem, but using unsigned arithmetic instead.

The UNIX/POSIX time format consists of two unsigned 32-bit integers, one
being the number of seconds since 00:00 UTC 21 January 1970 AD (the
"Epoch", or timescale zero), the other being the number of decimal
nanoseconds into the current second. (Ref: IEEE Std 1003.1-1996 chapter
14)


> I presume the reason for the original range was to minimize the amount
> of code inside Calendar which needed to be devoted to leap year
calculations.  
> 1901..2099 is the longest consecutive interval which includes today for 
> which the simple rule that every 4 years is a leap year applies.  Neither 1900
> nor 2100 are leap years, due to the second order correction in the
> leap year formula.

This is also partly the reason that UNIX/POSIX time is defined to roll
over in 2100 AD.  The other reason was to avoid the complexities of
multiprecision artithmetic, and the largest universally available integer
was and is still 32 bits.


> We saw no reason to change the Year_Number range during the
> Ada 9X revision.  We figured we wanted to leave something to the
> Ada 205X revision ;-).

By then, everybody will have at least 64-bit integer arithmetic, and
32-bit machines will be used only in toys and toasters.


Joe Gwinn

Re: Y2K Issues

[Joe Gwinn]

In article <gwinn-1910981944080001@d133.dial-6.cmb.ma.ultra.net>,
gwinn@ma.ultranet.com (Joe Gwinn) wrote:

> The UNIX/POSIX time format consists of two unsigned 32-bit integers, one
> being the number of seconds since 00:00 UTC 21 January 1970 AD (the
> "Epoch", or timescale zero), the other being the number of decimal
> nanoseconds into the current second. (Ref: IEEE Std 1003.1-1996 chapter
> 14)

That should be 1 January 1970, not 21 January.  Sorry; I didn't notice
that I had fat-fingered the date.  Thanks to those who pointed this out.

Joe Gwinn

Re: Y2K Issues

[dennison]

In article <362B8D2F.802F42E6@lmco.com>,
  Howard W LUDWIG <howard.w.ludwig@lmco.com> wrote:

> Perhaps our successors in 2050 will start debating about the Y2100 issue
> and the need to fix it in Ada 5X.  :-)  Then Year_Number can be redefined

Hmmm. It appears we have a year 2083 problem with language revision names. :-)

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Y2K Issues

[Michael F Brenner]

>> Perhaps our successors in 2050 will start debating about the Y2100 issue
>> and the need to fix it in Ada 5X.  :-)  Then Year_Number can be redefined

> Hmmm. It appears we have a year 2083 problem with language revision names. :-)

That can be fixed by referring to it as Ada 200X for the next revision.

 

Re: Y2K Issues

[Robert I. Eachus]

In article <362B8D2F.802F42E6@lmco.com> Howard W LUDWIG <howard.w.ludwig@lmco.com> writes:

 > [Note:  The fully general rule for leap year is that Year is a leap year
 > if and only if
 >   (Year mod 4) = 0 and
 >   ((Year mod 100) /= 0 or (Year mod 400) = 0).]

   Actually, there is another reason to wait to fix the Ada "Doom
Date" of December 31, 2099.  The current "Gregorian" calendar is
accurate to about one day in 3000 years.  Several proposals for how to
"fix" the leap year to deal with this have been proposed, most of
which would make the year 4000 AD not a leap year in contradiction to
the above rule.  I keep hoping that some government (or a Pope again)
will get around to dealing with this issue, since it is actually
starting to become important.  (You may not build things expected to
work for over 2000 years, but there is already one satellite in orbit
with an expected useful lifetime four times that.)
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Y2K Issues

[Mark Bennison]

eachus@spectre.mitre.org (Robert I. Eachus) thought long and hard and
wrote:

<snip>
>starting to become important.  (You may not build things expected to
>work for over 2000 years, but there is already one satellite in orbit
>with an expected useful lifetime four times that.)

Just to satisfy my curiosity... 

Why would a satellite be designed with an expected useful lifetime of
8000 years? What does it do that will still be of interest in that
time frame?

Cheers,

Mark.
-- 
Mark Bennison MBCS,               +-----------------------------------+
Software Group Technical Manager, | All opinions expressed are my own |
Dynamics Division.                +-----------------------------------+
"Never lose your ignorance, you can't replace it." - Andy Capp

Re: Y2K Issues

[dennison]

In article <362f066a.164357874@news.geccs.gecm.com>,
  mark.bennison@gecm.com (Mark Bennison) wrote:
> eachus@spectre.mitre.org (Robert I. Eachus) thought long and hard and
> wrote:
>
> <snip>
> >starting to become important.  (You may not build things expected to
> >work for over 2000 years, but there is already one satellite in orbit
> >with an expected useful lifetime four times that.)
>
> Just to satisfy my curiosity...
>
> Why would a satellite be designed with an expected useful lifetime of
> 8000 years? What does it do that will still be of interest in that
> time frame?

Perhaps it's supposed to keep track of continental drift. :-)

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Y2K Issues

[Robert I. Eachus]

In article <70nr92$9fo$1@nnrp1.dejanews.com> dennison@telepath.com writes:

 > > Why would a satellite be designed with an expected useful lifetime of
 > > 8000 years? What does it do that will still be of interest in that
 > > time frame?

 > Perhaps it's supposed to keep track of continental drift. :-)

  It IS used for that among other things.  The intent was to have a
satellite whose position could be very accurately measured and
predicted so that second order gravitational effects could be measured
accurately.  One use is to detect differences in density deep inside
the earth.

  The satellite itself is mostly a big ball of dense metal.  If you
put such a hazard to navigation in orbit, you want to make sure that
it can be detected and tracked for a long time.  So instead of solar
cells and transponders, you use dipole antennas. (Also helps reduce
atmospheric drag.)

  Now, you want to predict the orbit far into the future.  The only
usable form of time for that purpose currently is the astronomical
Julian date.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Y2K Issues

[Michael Feldman]

In article <362B8D2F.802F42E6@lmco.com>,
Howard W LUDWIG  <howard.w.ludwig@lmco.com> wrote:

[snip]
>
>[Note:  The fully general rule for leap year is that Year is a leap year
>if and only if
>  (Year mod 4) = 0 and
>  ((Year mod 100) /= 0 or (Year mod 400) = 0).]
>
Indeed.

As it so happens, I just saw this juicy bit of news:

According to "PC Week", issue of 10/19/98, Microsoft's
SQL Server 6.5's task manager refuses to recognize Feb. 
29, 2000 as a valid date. Apparently Microsoft's programmers 
never learned the real rules for leap years - a year divisible 
by 400 _is_ one. Microsoft has acknowledged the bug and will
fix it in a "service pack" (Microsoft jargon for a patch).

Unlike the Y2K "problem", which is caused by the unintended
consequences of an old but intentional engineering decision 
(2-digit years in the days of expensive storage), the leap-year
bug is a _bug_, and is, apparently much more widespread than
just this Microsoft case. In scouring code for the 2-digit
problem, they are discovering the bug as well.

Amazing. Where did these people go to school?

Mike Feldman

Re: Y2K Issues

[dennison]

In article <710nnc$jop@felix.seas.gwu.edu>,
  mfeldman@seas.gwu.edu (Michael Feldman) wrote:

> As it so happens, I just saw this juicy bit of news:
>
> According to "PC Week", issue of 10/19/98, Microsoft's
> SQL Server 6.5's task manager refuses to recognize Feb.
> 29, 2000 as a valid date. Apparently Microsoft's programmers
> never learned the real rules for leap years - a year divisible
> by 400 _is_ one. Microsoft has acknowledged the bug and will
> fix it in a "service pack" (Microsoft jargon for a patch).
...
> Amazing. Where did these people go to school?

Don't be quite so hard on uSoft. ObjectAda 7.1.1 had this exact same problem.
I understand it has been fixed in the current release, though.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Y2K Issues

[dewarr]

In article <7125a8$e7u$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> In article <710nnc$jop@felix.seas.gwu.edu>,


> Don't be quite so hard on uSoft. ObjectAda 7.1.1 had this exact same problem.
> I understand it has been fixed in the current release, though.


The remarkable thing about this (quite common) leap year bug is that it is
a great example of how a little knowledge can be a dangerous thing. Someone
who knows nothing about century corrections will get things right, someone
who knows how centuray corrections work will get things right, it is only
someone who knows about century corrections, but does not know how they
work who gets things wrong. I have always assumed that one of the reasons
for the range of years in Ada is precisely that you don't have to worry
about century corrections :-)

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Y2K Issues

[John Herro]

dennison@telepath.com wrote:
> Don't be quite so hard on uSoft.
> ObjectAda 7.1.1 had this exact same problem.
It's a slightly different problem.  OA 7.1.1 (and many applications it
produces) fail on 29 Feb. of *any* leap year, not just century leap years.
- John Herro
http://members.aol.com/AdaTutor
----------
The mathematical relationship between Christmas and Halloween:
31    = 25
  oct     dec

Re: Y2K Issues

[Tucker Taft]

dewarr@my-dejanews.com wrote:

: In article <7125a8$e7u$1@nnrp1.dejanews.com>,
:   dennison@telepath.com wrote:
: > In article <710nnc$jop@felix.seas.gwu.edu>,


: > Don't be quite so hard on uSoft. ObjectAda 7.1.1 had this exact same problem.

That surprises me, because the package Calendar we have shipped with
our Ada 95 front end since the beginning has the following leap_year
function (original comment included):

    function leap_year (the_year : year_number) return Boolean is
    -- This algorithm is good for 1901-2099 (LRM), but not beyond.
    begin
        return ((the_year rem 4) = 0);
    end leap_year;

: > I understand it has been fixed in the current release, though.

That's good.  Maybe there is an interesting story here (or perhaps
this whole thing is apocryphal?).

: The remarkable thing about this (quite common) leap year bug is that it is
: a great example of how a little knowledge can be a dangerous thing. Someone
: who knows nothing about century corrections will get things right, someone
: who knows how century corrections work will get things right, it is only
: someone who knows about century corrections, but does not know how they
: work who gets things wrong. 

Interestingly, we found a similar problem in the old Meridian front end, 
which was written in Pascal, which we licensed many moons ago for some
Ada 83 products.  The programmer went to some effort to correct for years 
that were a multiple of 100 and of 400, but ended up with it exactly wrong.  

Luckily, this was not in the Calendar package, but
rather in the code which printed the date on the listing.  The net
effect is that listings using compilers based on the Meridian front end
will print the wrong date from February 29th, 2000 to December 30th, 2000.
If I remember correctly, they did manage to self-correct by the time
2001 comes along, so January 1st, 2001 will be correct.  I don't know
what will happen on December 31st, 2000.  I suspect they will either
print January 0, 2001, or December 32, 2000.

: ...I have always assumed that one of the reasons
: for the range of years in Ada is precisely that you don't have to worry
: about century corrections :-)

So much for trying to simplify the problem...

: Robert Dewar

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company

Re: Y2K Issues (well, not really...)

[Dave Wood]

Tucker Taft wrote:
> 
> : In article <7125a8$e7u$1@nnrp1.dejanews.com>,
> :   dennison@telepath.com wrote:
> 
> : > Don't be quite so hard on uSoft. ObjectAda 7.1.1 had this exact same problem.
> 
> That surprises me, because the package Calendar we have shipped with
> our Ada 95 front end since the beginning has the following leap_year
> function (original comment included):

[snip]

> 
> : > I understand it has been fixed in the current release, though.
> 
> That's good.  Maybe there is an interesting story here (or perhaps
> this whole thing is apocryphal?).

I don't know how good the story is - that's for others
to decide!  To me, I'm afraid, the story is no more
exciting than any other ordinary bug story - no major
database corruptions, power outages, downed airlines,
or other significant catastophes.  We leave those to
C code.  :)

The problem had nothing to do with whether or not the year
2000 is a leap year.  As Tucker has said, our runtime
understands that this is so.

The problem was that our implementation of Ada.Real_Time
caused an internal runtime exception when any Ada
application was executed on *any* leap year day, 1904, 1996,
2000, 2060, etc.  It just happened to be caught during our
routine year 2000 testing which includes leap tests.

Although the issue was detected just prior to the current
7.1.2 release, we felt no great need to delay that 
release to include a fix, given that the problem is
unlikely to manifest itself for another 1.5 years.  The
fix is in the upcoming 7.1.3 release.

For those who might have an immediate need, a patch is
posted on our web site in the support area.

-- Dave Wood, Aonix
-- Product Manager, ObjectAda for Windows
-- http://www.aonix.com

Re: Y2K Issues

[dennison]

In article <F1I5z2.9K8.0.-s@inmet.camb.inmet.com>,
  stt@houdini.camb.inmet.com (Tucker Taft) wrote:
> : In article <7125a8$e7u$1@nnrp1.dejanews.com>,
> :   dennison@telepath.com wrote:

> : > Don't be quite so hard on uSoft. ObjectAda 7.1.1 had this exact same
problem.
>
> That surprises me, because the package Calendar we have shipped with
> our Ada 95 front end since the beginning has the following leap_year
> function (original comment included):
(snip)
> That's good.  Maybe there is an interesting story here (or perhaps
> this whole thing is apocryphal?).

Well, no. It has been verified on the Intel-ObjectAda mailing list by Dave
Wood. I may have phrased it vaguely because I don't trust my memory on the
particulars, and I was too lazy to look it up in my mailing-list archives.
But since you are interested...

I don't know if there is a public archive of the Intel-ObjectAda mailing list,
but if there is, the thread name is "Intel-OA:Leap Day Error". First post was
9/16/98. The following is my "book report" on the thread:

The problem was *not* in calendar, but internal to ObjectAda compiled
applications, reportedly even a "Hello World" program. Programs run on any
Feb 29 GMT may (will?) have the problem. The reported symptom is the program
bombing immediately with "ERROR: reentering exception manager for the 10th
time, EIP=00000000".

Also, while I'm correcting myself, it is *not* fixed in the current version
of ObjectAda. It looks like it should be in the *next* version, which of
course is due RSN. :-) Aonix made some rumblings about making a patch
available in the meantime, but I have seen nothing further on the subject.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Y2K Issues

[Dave Wood]

dennison@telepath.com wrote:
> 
> Also, while I'm correcting myself, it is *not* fixed in the current version
> of ObjectAda. It looks like it should be in the *next* version, which of
> course is due RSN. :-) Aonix made some rumblings about making a patch
> available in the meantime, but I have seen nothing further on the subject.
> 

T.E.D was too busy day-dreaming about the glories of 
the RSN v7.1.3, and he missed the Oct. 15th announcement 
of the leap day patch. :)

It can be found at:

http://www.aonix.com/Support/Ada/Patches/objectada.htm

-- Dave Wood, Aonix
-- Product Manager, ObjectAda for Windows
-- http://www.aonix.com

Re: Y2K Issues

[Robert A Duff]

mfeldman@seas.gwu.edu (Michael Feldman) writes:

> Unlike the Y2K "problem", which is caused by the unintended
> consequences of an old but intentional engineering decision 
                  ^^
> (2-digit years in the days of expensive storage),

Hmm.  I wouldn't call it a single design decision.  Lots and lots of
folks made this same decision, semi-independently of each other.  I
imagine it was sometimes intentional, and sometimes not.

Anyway, IMHO these decisions aren't the cause of the Y2K problem.  Lack
of abstraction is.  If you wrote a million-line program a long time ago,
and decided 2-digit years were the right trade-off, and documented that
fact, and documented why, and encapsulated that decision in a single
module, then finding and fixing the problem would be no big deal.  On
other hand, if you scatter that knowledge all over the program, then
it's a huge amount of trouble to find all those places.  If you lose the
source code, it's even worse.

I would be naughty if I didn't mention Ada in a posting to this
newsgroup, so I'll just point out that Ada makes it a lot easier to
encapsulate this sort of thing than COBOL does.

I also can't help but point out that two 8-bit quantities can of course
store a year-range of 65,536 years, so something's wrong when somebody
decides to use 16 bits to represent a 100-year range, because they're
short on memory, and 32 bits is too costly.  That kind of decision
sounds more "convenient" or "expedient" than "intentional".

>...the leap-year
> bug is a _bug_, and is, apparently much more widespread than
> just this Microsoft case. In scouring code for the 2-digit
> problem, they are discovering the bug as well.
> 
> Amazing. Where did these people go to school?

Maybe I'm just cynical, but I don't find bugs to be "amazing" anymore.
;-)

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Y2K Issues

[Joel Seidman]

Robert A Duff wrote:
> I also can't help but point out that two 8-bit quantities can of course
> store a year-range of 65,536 years, so something's wrong when somebody
> decides to use 16 bits to represent a 100-year range, because they're
> short on memory, and 32 bits is too costly.  That kind of decision
> sounds more "convenient" or "expedient" than "intentional".

Obviously if you really wanted to pack numbers you'd use BCD or binary.
I've always thought attributing the "saving memory" motivation that you
see in popular explanations is overly kind, a bit of a social lie.

Re: Y2K Issues - Warning Off-Topic

[Al Christians]

Joel Seidman wrote:
> 
> Robert A Duff wrote:
> > I also can't help but point out that two 8-bit quantities can of course
> > store a year-range of 65,536 years, so something's wrong when somebody
> > decides to use 16 bits to represent a 100-year range, because they're
> > short on memory, and 32 bits is too costly.  That kind of decision
> > sounds more "convenient" or "expedient" than "intentional".
> 
> Obviously if you really wanted to pack numbers you'd use BCD or binary.
> I've always thought attributing the "saving memory" motivation that you
> see in popular explanations is overly kind, a bit of a social lie.

Many of the business systems originated in the 1401 era.  The IBM 1401
(a vey popular early-60's business machine) used numeric characters, but 
it was possible to add an overpunch that would indicate an overflow out
of the high order position.  With a variety of overpunches, a few
centuries 
could be accomodated in a 2-digit field, more or less transparently to
the 
programmer. There was no comparable support for bcd or binary formats on 
those machines.  When the 360's became the typical business machine, the 
2-digit-year record formats persisted but the overpunch facility was
lost.  
I guess anyone who gave it any thought figured the overpunches could
come 
back if and when they were ever needed.

It wasn't just space that was being saved.  Punched cards were a
standard
storage medium.  For example, large sorts were done more on card sorters
than on other devices.  The requirement of fitting a record on a card
and
the limitation of card interpreters to only print the first 60 or so 
columns of data on the card were also strong motivation for 2-digit (or 
less) year fields.   

Al

Re: Y2K Issues

[dewarr]

In article <wccww5n0wzc.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:

> I also can't help but point out that two 8-bit quantities can of course
> store a year-range of 65,536 years, so something's wrong when somebody
> decides to use 16 bits to represent a 100-year range, because they're
> short on memory, and 32 bits is too costly.  That kind of decision
> sounds more "convenient" or "expedient" than "intentional".


Any COBOL programmer worrying about space would use two 4-bit fields to
hold the date, using COMP-3 (packed decimal), but of course this still
allows 256 combinations, and indeed some of the standard Y2K solution
approaches use this extra space for coding (a nice solution because it
is backwards compatible with existing data files).

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Y2K Issues

[dewarr]

In article <710nnc$jop@felix.seas.gwu.edu>,
  mfeldman@seas.gwu.edu (Michael Feldman) wrote:

> Unlike the Y2K "problem", which is caused by the unintended
> consequences of an old but intentional engineering decision
> (2-digit years in the days of expensive storage), the leap-year
> bug is a _bug_, and is, apparently much more widespread than
> just this Microsoft case. In scouring code for the 2-digit
> problem, they are discovering the bug as well.
>
> Amazing. Where did these people go to school?


I object to Mike characterizing the Y2K problem as other than a bug. yes
I know that this is a popular attitude, particularly encouraged by software
companies who want you to pay for Y2K "enhancements", but the fact remains
it is indeed a bug. Saving storage at the expense of malfunction is not an
acceptable trade off. Any reasonably careful programmer should have forseen
the problem and dealt with it (using any of the approaches that are familiarly
used for "fixing" this "problem", e.g. windowing.

Someone reminded me that I first mentioned the Y2K problem to them in 1975,
and certainly I was not the only one to forsee this problem.

Unless the specification of the problem specifically noted that the software
was intended to stop working in 2000, introducing this kind of bug into
programs was indeed a bug. Just because a bug is a huge one with horrible
consequences does not stop it being a bug!

Note that the storage usage argument is a weak one. Many of the Y2K solutions
solve the problem without using extra storage (fixed and sliding windows,
various encodings etc).

Robert Dewar



-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Y2K Issues

[system]

dewarr@my-dejanews.com writes:

>Someone reminded me that I first mentioned the Y2K problem to them in 1975,
>and certainly I was not the only one to forsee this problem.

Show of hands please, 

Who was aware of the Y2K problem before 1995? 1990?  1985? 1980? 1975?

Who was aware of the Y2K problem as it affects embedded programs before
1995? 1990?  1985? 1980? 1975?

There is a group on campus making allegations of a gov't coverup....

Robert
(whose answers would be roughly 1992 and, rather embarassingly, 1998)
Morphis@physics.niu.edu
Real Women change tires			abuse@uu.net postmaster@uu.net
Real Men change diapers                 security@uu.net

Re: Y2K Issues

[Al Christians]

system@niuhep.physics.niu.edu wrote:
> 
> dewarr@my-dejanews.com writes:
> 
> >Someone reminded me that I first mentioned the Y2K problem to them in 1975,
> >and certainly I was not the only one to forsee this problem.
> 
> Show of hands please,
> 
> Who was aware of the Y2K problem before 1995? 1990?  1985? 1980? 1975?
> 
> Who was aware of the Y2K problem as it affects embedded programs before
> 1995? 1990?  1985? 1980? 1975?
> 
> There is a group on campus making allegations of a gov't coverup....
> 

I first became aware of the possible magnitude of the Yr2k panic back
around 1978, when a friend told me of a session on the topic at a SHARE 
(big IBM mainframe users' group) meeting.  So it was not a total coverup 
back in the years when Ada 83 was being put together.

I made appropriate note of the oncoming debacle, and have ever since
been relatively successful at abating production of Y2k bugs in those 
spheres where I have influence.  This means, of course, that I have 
little experience fixing Y2k bugs, and I am thus not qualified for 
all the big-money Y2k contracts now available.  

Al

Re: Y2K Issues

[Marin David Condic]

I remember being aware of the Y2K problem when I got my first job programming in
Cobol in 1980. Looking at the financial code and seeing all the dates coded as
two digits, it was pretty clear that come Y2K there would be a problem. I talked
to my supervisor about it, observing that the argument about saving space was
beginning to get less and less important and that maybe we ought to think about
conversions before it was a pressing matter. The answer was basically "You can't
really believe that these ancient decks were still going to be around in 2000
(some had been there since the 60s) and that anyway, we'd all be retired or in
different jobs by then, so it would be Someone Else's Problem. And besides,
there's too much historical data that would have to be corrected" (I have no
idea if those systems are still being used.)

There's actually some merit to this. In designing anything, you can't generally
assume it is going to be around forever, so you have to build it with some
thought to an expected life and trust that those who come after will build a
better one when this wears out. And the youth among us may not recall that back
in that time frame, two extra bytes over a million records started adding up to
non-trivial disk space. Lots of other record fields were condensed to very small
storage - not allowing for future expansion - specifically because of this. It
was a trade-off. Disk space now for life expectancy 20 years from now.

Just remember that the question of malicious intent would not be there for
anyone building systems a bunch of years ago, but may be negligence or
unprofessional malfeasance if it were being built into systems today. (Windows
95 comes to mind.)

Embedded systems? Lots of them don't really care. You start time from some
arbitrary epoch (like at the time of power-up) and start counting. I've never
worked a system where it used real calendar dates. The threat may be there in
some and not there in others. The question is, even if it is a minority of those
systems, are they the ones that cause disaster?

Government coverup? They've got too many other things to cover up - like Monica
Lewinski, etc. - to be worried about this!

MDC

system@niuhep.physics.niu.edu wrote:

> dewarr@my-dejanews.com writes:
>
> >Someone reminded me that I first mentioned the Y2K problem to them in 1975,
> >and certainly I was not the only one to forsee this problem.
>
> Show of hands please,
>
> Who was aware of the Y2K problem before 1995? 1990?  1985? 1980? 1975?
>
> Who was aware of the Y2K problem as it affects embedded programs before
> 1995? 1990?  1985? 1980? 1975?
>
> There is a group on campus making allegations of a gov't coverup....
>
> Robert
> (whose answers would be roughly 1992 and, rather embarassingly, 1998)
> Morphis@physics.niu.edu
> Real Women change tires                 abuse@uu.net postmaster@uu.net
> Real Men change diapers                 security@uu.net

--
Marin David Condic
===========================================================
    "A government that is big enough to give you all you want is big
    enough to take it all away."

        --  Barry Goldwater
===========================================================

Re: Y2K Issues

[Robert I. Eachus]

In article <363E5AAC.E2F0AB7D@flinet.com> Marin David Condic <diespammer@flinet.com> writes:

   > Who was aware of the Y2K problem before 1995? 1990?  1985? 1980? 1975?
   >
   > Who was aware of the Y2K problem as it affects embedded programs before
   > 1995? 1990?  1985? 1980? 1975?

   There are a lot of people who were aware of the Y2K problem in the
late sixties, and it is very embarrassing that a lot of banks who
fixed their loan software in time for 1970 (for thirty year mortages)
failed to take the lesson to heart and require that any new software
be Y2K compliant back then.

   Incidently just to rub it in, OS360 had a millenial bug that was a
decade bug--the year was internally stored as one decimal digit, and
OS360 would fail to boot if it overflowed.  This was fixed in the
English language versions in plenty of time, but some of the European
versions were not ready for January 1, 1970.





--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Y2K Issues

[dewarr]

In article <EACHUS.98Nov4181012@spectre.mitre.org>,
  eachus@spectre.mitre.org (Robert I. Eachus) wrote:

    There are a lot of people who were aware of the Y2K problem in the
> late sixties, and it is very embarrassing that a lot of banks who
> fixed their loan software in time for 1970 (for thirty year mortages)
> failed to take the lesson to heart and require that any new software
> be Y2K compliant back then.


That's a claim that definitely needs convincing evidence. I do not believe
for a moment that it was true. Please cite chapter and printed verse on this.

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Y2K Issues

[Robert I. Eachus]

In article <71sbsc$5q5$1@nnrp1.dejanews.com> dewarr@my-dejanews.com writes:

 > That's a claim that definitely needs convincing evidence. I do not believe
 > for a moment that it was true. Please cite chapter and printed
 > verse on this. 

    What you want Robert?  The point I made is self-evident.  Banks
fixed their systems to work for mortgages thirty years ago, and some
of those same banks had Y2K problems in the last few years.  Any bank
that was in the mortgage business thirty years ago, and had Y2K fixes
to make recently proves my point, and there were an awful lot of them.

  To make it much more personal, I worked on a bank system in the
sixties to get it ready for mortgages that expired in 2000 or later
(for First Pennsylvania Bank).  Actually I worked for the contractor
that maintained the software not the bank.  We had some pretty
horrendous testing problems because OS360 was not 1970! compliant--it
internally stored the year in one digit (actually four bits) and
rolling from 9 to A caused all sorts of problems.  IBM did get a 1970
compliant version out in 1969, but some Europeans didn't get it in
time.

  Anyway, when all this was over, I asked the bank VP in charge of
data processing what he was going to do about some Y2K problems we had
noticed.  He said, "I'm going to let my successor's successor worry
about it.  I'll be long gone.  Besides, this software will probably
all be replaced by then."

    Neither he or First Pennsylvania survived long enough to see Y2K,
so I guess he made the right decision.

    But I do know of banks that really got serious about Y2K issues in
the 1970's, and I also know personally one bank President who told me
he intended to sell the bank when the time came, and he did.  (Nashua
Federal Savings Bank, sold to Bay Banks who then merged with Bank
Boston...)
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Y2K Issues

[Jerry van Dijk]

dewarr@my-dejanews.com wrote:

:   eachus@spectre.mitre.org (Robert I. Eachus) wrote:

:     There are a lot of people who were aware of the Y2K problem in the
: > late sixties, and it is very embarrassing that a lot of banks who
: > fixed their loan software in time for 1970 (for thirty year mortages)
: > failed to take the lesson to heart and require that any new software
: > be Y2K compliant back then.

: That's a claim that definitely needs convincing evidence. I do not believe
: for a moment that it was true. Please cite chapter and printed verse on this.

I do not know if the people writing those applications had Y2K problems on
their mind, but yes, definitively, banks have been confronted with this
problem for every application that involved long term credits, like mortages,
leasing (think: airplanes, oil platforms, and such) and other long-term 
ventures for at least the last twenty years.

Jerry.

-- 
-- Jerry van Dijk  | email: jdijk@acm.org
-- Leiden, Holland | member Team-Ada
-- Ada & Win32: http://stad.dsl.nl/~jvandyk

Re: Y2K Issues

[dewarr]

In article <F1z5ow.8B@jvdsys.nextjk.stuyts.nl>,
  jerry@jvdsys.nextjk.stuyts.nl (Jerry van Dijk) wrote:
> dewarr@my-dejanews.com wrote:
>
> :   eachus@spectre.mitre.org (Robert I. Eachus) wrote:
>
> :     There are a lot of people who were aware of the Y2K
problem in the
> : > late sixties, and it is very embarrassing that a lot
of banks who
> : > fixed their loan software in time for 1970 (for
thirty year mortages)
> : > failed to take the lesson to heart and require that
any new software
> : > be Y2K compliant back then.
>
> : That's a claim that definitely needs convincing
evidence. I do not believe
> : for a moment that it was true. Please cite chapter and
printed verse on this.
>
> I do not know if the people writing those applications
had Y2K problems on
> their mind, but yes, definitively, banks have been
confronted with this
> problem for every application that involved long term
credits, like mortages,
> leasing (think: airplanes, oil platforms, and such) and
other long-term
> ventures for at least the last twenty years.



Twenty years = 1978, and of course we agree that people
were aware of Y2K then, indeed my post that started this
thread noted that.

But Robert Eachus claimed ten years earlier (late 60's),
and that I find dubious.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Y2K Issues

[Al Christians]

dewarr@my-dejanews.com wrote:
> 
> Twenty years = 1978, and of course we agree that people
> were aware of Y2K then, indeed my post that started this
> thread noted that.
> 
> But Robert Eachus claimed ten years earlier (late 60's),
> and that I find dubious.
> 

I've been doing a little informal research on my bookshelf to see 
what level of awareness of y2k problems was in times past and what 
a reasonably literate software developer would have seen.   Here's 
some of what I've found:

1. A good late 1980's Cobol text has examples with 2-digit year fields.
2. Cobol's CURRENT-DATE returned 2-digit year through Cobol 85.  Even
somebody who knew how bad this was might still use 2-digit years in
their code, because that was the standard way, and the standard way
would be compatible with the anticipated standard fix that has never
arrived.
3. A 1993 book on user interface screen design has 2-digit year fields
in the example screens, and gives results showing how research finds 
longer data fields produce much higher data entry error rates -- no 
mention of y2k problems.  (I know of several very large systems written 
20 or more years ago with file formats and processing algorithms that 
accomodate y2k fine, but that are rendered worthless by y2k because the 
screens and I/O routines are non-compliant)   
4. Yourdon and Constantine's _Structured_Design_, a very influential 
work circa 1978, includes a lengthy example with data dictionary
entries showing 6-digit date fields.  Curiously, Yourdon is now one of
the authors of books telling how to handle the problem.

 
Al

Re: Y2K Issues

[Jerry van Dijk]

Al Christians (achrist@easystreet.com) wrote:
: dewarr@my-dejanews.com wrote:
: > 
: > Twenty years = 1978, and of course we agree that people
: > were aware of Y2K then, indeed my post that started this
: > thread noted that.
: > 
: > But Robert Eachus claimed ten years earlier (late 60's),
: > and that I find dubious.
: > 

: I've been doing a little informal research on my bookshelf to see 
: what level of awareness of y2k problems was in times past and what 
: a reasonably literate software developer would have seen.   Here's 
: some of what I've found:

: 1. A good late 1980's Cobol text has examples with 2-digit year fields.

Most financial software that I am aware of was at that time not
written in COBOL but PL/1. One reason this is stil done is to take
advantage of it's 22 digits accuracy.

Jerry.

-- 
-- Jerry van Dijk  | email: jdijk@acm.org
-- Leiden, Holland | member Team-Ada
-- Ada & Win32: http://stad.dsl.nl/~jvandyk

Re: Y2K Issues

[dewarr]

In article <F22tqs.3q@jvdsys.nextjk.stuyts.nl>,
  jerry@jvdsys.nextjk.stuyts.nl (Jerry van Dijk) wrote:
> Most financial software that I am aware of was at that
> time not
> written in COBOL but PL/1. One reason this is stil done
> is to take
> advantage of it's 22 digits accuracy.


Of course this statement may be true, but it simply means
that your experience was by no means representative. PL/1
even at its most successful point, never held a very large
share of the financial software market, and was always
hugely overshadowed by COBOL.

There are many reasons for writing in PL/1 rather than
COBOL, but in practice the difference between the 18 vs 22
digits of accuracy is not a very significant one, and of
course certainly not relevant to the subject material of
this post.

Of course PL/1 does have much better data abstraction than
COBOL, so one might hope that PL/1 programs would be less
sensitive to Y2K problems. Unfortunately, many PL/1
programs were written in COBOL style, and PL/1 goes out of
its way to accomodate this style (e.g. allowing completely
general use of anonymous types as in COBOL). Thus most PL/1
programs are in practice as bad as COBOL when it comes to
Y2K problems, at least that is my experience.

Language can make a difference, but often it is not *just*
the language, but the general style and approach of the
programmers in that language that is as significant. In the
case of Ada (let's get back on topic :-) it is most
certainly true that the data abstraction in Ada encourages
writing programs that are either less likely to have Y2K
problems in the first place, or be much easier to correct
if such problems exist. However, the important point is
that the Ada culture is such that programmers are likely to
take full advantage of these abstraction capabilities.
COBOL style code in PL/1 does not seem horrible at all,
COBOL style code in Ada would be rather disgusting (I am
talking now specifically about the style of data
declaration and data abstraction).

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Y2K Issues

[Gautier de Montmollin]

> I also note that the Ada 95 LRM (RM96;6.0) Ada.Calendar package defines
> the Year_Number as range 1901..2099. What happens in 2099? The world
> ends?

Someone in an hydrological bureau had the same shock today reading that
LRM topic in AdaHelp, but because of the 1901 problem: many archived time
series begin before 1901... (hydrology, geography etc.) => Calendar is
useless for it ! One has to program a Calendar bis. It's not that
the formulas for this purpose don't exist or are too complicated...
And what to think about astronomical calculations / previsions ?...

-- 
Gautier

--------
Homepage: http://www.unine.ch/math/Personnel/Assistants/Gautier/Montmollin.html
Software: http://www.unine.ch/math/Personnel/Assistants/Gautier/Gaut_FTP.htm.

Re: Y2K Issues

[Arthur Evans Jr]

In article <36365724.EF1CC215@maths.unine.ch>,
Gautier de Montmollin <gautier.demontmollin@maths.unine.ch> wrote:

> Someone in an hydrological bureau had the same shock today reading that
> LRM topic in AdaHelp, but because of the 1901 problem: many archived time
> series begin before 1901... (hydrology, geography etc.) => Calendar is
> useless for it !

The problem is also important for genealogical research, in which dates
hundreds of years in the past are needed.  I've long represented dates
in genealogy records as YYYY.MMDD, usually in a text field.  Note that
dates so represented sort properly, whether stored as text strings or as
decimal numbers.

Art Evans

Make the obvious fix to my address to reply to me.

Re: Y2K Issues

[adam]

In article <717kpq$7cv$1@platane.wanadoo.fr> "Jean-Pierre Rosen"
<rosen.adalog@wanadoo.fr> writes:
>
> Gautier.DeMontmollin@maths.unine.ch a \351crit dans le message ...
> >"Standard" depends on what usage is expected from Ada language...
> >Since it is a powerful and comfortable tool in many other domains than
> >real-time systems (I think in present context to statistics or nature
> >sciences), the 1901..2099 range seems to me _a bit_ narrow.
> >Apparently - as you write - it's not a problem of sparing some bits or
> >adding lots of leap years code. Of course it's very easy to write a sort
> >of Long_Calendar from GNAT library sources but I already see people
> >using the wrong Calendar etc... But maybe there are solid reasons for that
> >range, like the ability of doing 8-bit arithmetics (199<256) with the
> years...
>
>
> You have to put some bounds somewhere. Allowing dates before 1600
> for example (actually 1543 ? not sure) is really asking for trouble
> (that's when the Julian calendar switched to Gregorian).

To make things worse, there's no one date when the calendar switched to
Gregorian.  IIRC, the Catholic nations all switched when Pope Gregory
designed the change, but everyone else lagged behind.  Britain didn't make
the switch until the mid-18th century.	Plus, in Sweden, I seem to recall
reading that they tried to be clever about how they made the change and then
messed it up, with the result that one year they had to add a 30th day to
February.  So if you're going to extend the Calendar package to handle years
going back several centuries, you have to make sure the package allows
February 30, at least for one specific year that I don't remember, if you're
dealing with Swedish dates.

Of course, even the current Calendar package is going to have problems with
Russian dates, since they stayed with the Julian calendar until 1918 (with
the result that the October Revolution really happened in November).  I
suppose it was a flaw in the design of Ada that the designers didn't consider
that case---perhaps they should have made the year subrange 1919..2099 to
avoid this problem.

Next, someone will be asking why there's no Ada.Calendar.Jewish in the
standard . . .

				-- Adam

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Y2K Issues

[Al Christians]

adam@irvine.com wrote:
> 
> Of course, even the current Calendar package is going to have problems with
> Russian dates, since they stayed with the Julian calendar until 1918 
>

Also in the future.  The leap year that comes in year 2800 in US is 
delayed until 2900 in the eastern calendar.  IOW, their even-century
leap years alternate between 400 and 500 year intervals.

Al

Re: Y2K Issues

[Samuel Mize]

In article <718200$efa$1@nnrp1.dejanews.com>,  <adam@irvine.com> wrote:
>Of course, even the current Calendar package is going to have problems with
>Russian dates, since they stayed with the Julian calendar until 1918 (with
>the result that the October Revolution really happened in November).  I
>suppose it was a flaw in the design of Ada that the designers didn't consider
>that case---perhaps they should have made the year subrange 1919..2099 to
>avoid this problem.

No, no, it was a feature designed to support the Cold War.  They were
hoping the Russians would steal the Ada technology, and then all their
systems would crash or become inaccurate.

Sam

PS :-) duh

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

Re: Y2K Issues

[Robert I. Eachus]

In article <718200$efa$1@nnrp1.dejanews.com> adam@irvine.com writes:

 > Of course, even the current Calendar package is going to have
 > problems with Russian dates, since they stayed with the Julian
 > calendar until 1918 (with the result that the October Revolution
 > really happened in November).  I suppose it was a flaw in the
 > design of Ada that the designers didn't consider that
 > case---perhaps they should have made the year subrange 1919..2099
 > to avoid this problem.

   The Greek government changed in the 1930's, where do you stop?
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Y2K Issues

[dewar]

In article <36365724.EF1CC215@maths.unine.ch>,
  Gautier de Montmollin <gautier.demontmollin@maths.unine.ch> wrote:

> Someone in an hydrological bureau had the same shock today reading that
> LRM topic in AdaHelp, but because of the 1901 problem: many archived time
> series begin before 1901... (hydrology, geography etc.) => Calendar is
> useless for it ! One has to program a Calendar bis. It's not that
> the formulas for this purpose don't exist or are too complicated...
> And what to think about astronomical calculations / previsions ?...


Why should this be a shock? The standard library packages are provided to
cover standard needs, not all possible needs! If you need a calendar package
that covers a longer period, then build, buy or otherwise acquire one, just
as you would do for lots of other specialized functionality.

Note that if you use a compiler with open sources, such as GNAT, then you
have the existing sources for Ada.Calendar, and making your own calendar
package with different characteristics by modifying this package is fairly
straightforward. Basically all you have to do is to add the century
corrections for leap years (the GNAT format for Duration is able to
accomodate a MUCH larger range than the required range in Ada).

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Y2K Issues

[Gautier.DeMontmollin]

> Why should this be a shock? The standard library packages are provided to
> cover standard needs, not all possible needs! If you need a calendar package
> that covers a longer period, then build, buy or otherwise acquire one, just
> as you would do for lots of other specialized functionality.

"Standard" depends on what usage is expected from Ada language...
Since it is a powerful and comfortable tool in many other domains than
real-time systems (I think in present context to statistics or nature
sciences), the 1901..2099 range seems to me _a bit_ narrow.
Apparently - as you write - it's not a problem of sparing some bits or
adding lots of leap years code. Of course it's very easy to write a sort
of Long_Calendar from GNAT library sources but I already see people
using the wrong Calendar etc... But maybe there are solid reasons for that
range, like the ability of doing 8-bit arithmetics (199<256) with the years...

-- 
Gautier

Re: Y2K Issues

[Jean-Pierre Rosen]

Gautier.DeMontmollin@maths.unine.ch a �crit dans le message ...
>"Standard" depends on what usage is expected from Ada language...
>Since it is a powerful and comfortable tool in many other domains than
>real-time systems (I think in present context to statistics or nature
>sciences), the 1901..2099 range seems to me _a bit_ narrow.
>Apparently - as you write - it's not a problem of sparing some bits or
>adding lots of leap years code. Of course it's very easy to write a sort
>of Long_Calendar from GNAT library sources but I already see people
>using the wrong Calendar etc... But maybe there are solid reasons for that
>range, like the ability of doing 8-bit arithmetics (199<256) with the
years...


You have to put some bounds somewhere. Allowing dates before 1600 for
example
(actually 1543 ? not sure) is really asking for trouble (that's when the
Julian calendar
switched to Gregorian).  Note that for genealogy, you may well need dates
before that.
So, as some bound is required and the "natural" start (0) is clearly not
feasible, they
decided to stick to the "current" time, defined as the biggest range that
allowed for
the simplest calculations.
----------------------------------------------------------------------------
                  J-P. Rosen (Rosen.Adalog@wanadoo.fr)
      Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Y2K Issues

[Robert I. Eachus]

In article <717kpq$7cv$1@platane.wanadoo.fr> "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes:

 > You have to put some bounds somewhere. Allowing dates before 1600 for
 > example (actually 1543 ? not sure) is really asking for trouble
 > (that's when the Julian calendar switched to Gregorian).

   Ooooh boy is that asking for trouble.  I'm not going to try to
create a list of all the dates that various countries switched from
Julian to Gregorian calendars.  I'll just note that it spans five
centuries so far, and there are some countries that still don't use
EITHER Julian or Gregorian calendars.  Greece and Russia are two of
the countries that switched during the twentieth century.

 > Note that for genealogy, you may well need dates before that.

    Note that the problem is not with type Calendar.Time.  As Robert
Dewar pointed out for gnat, the underlying representation is probably
much wider than you need for genealogy or the like.  The problem is
that Year, Split, and Time_Of are defined in terms of the subtype
Year_Number.  Since it seems to be time to discuss enhancements to
Ada, why not a child package of Ada.Calendar like:

   package Ada.Calendar.Extended is

     subtype Year_Number is Integer range _implementation_defined_;
     ...
     function Year (Date: Time) return Year_Number;
     procedure Split(Date: in Time;
                     Year: out Year_Number;
                     Month: out Month_Number;
                     Day: out Day_Number;
                     Seconds: out Day_Duration);
     function Time_Of(Year: Year_Number;
                      Month: Month_Number;
                      Day: Day_Number;
                      Seconds: Day_Duration := 0.0);

   end Ada.Calendar.Extended;

   Of course, it is possible to write the body of such a package in an
implementation independent manner, but making it efficient requires
making it a child of Calendar.  Also, the only thing that has been
stopping me from proposing such a solution is a concern about how to
make use clauses reasonable. 

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Y2K Issues

[Dale Stanbrough]

Robert I. Eachus wrote:

" Ooooh boy is that asking for trouble.  I'm not going to try to
 create a list of all the dates that various countries switched from
 Julian to Gregorian calendars.  I'll just note that it spans five
 centuries so far, and there are some countries that still don't use
 EITHER Julian or Gregorian calendars.  Greece and Russia are two of
 the countries that switched during the twentieth century."
 

Don't we just need to support dates in the same way we support time,
i.e. have a universal date (like GMT), and then supply localisation
routines which allow different locations to convert from/to local 
calendars...

   package Calendar;
   package Calendar.Monotonic;
   package Calendar.Monotonic.Gregorian
   package Calendar.Monotonic.Julian;    

etc.
Does making these children of (Ada.)Calendar aren't we locking it into
a framework where people can't extend the hierachy because "only compiler
developers are allowed to extend the Ada hierachy"? (yes, i know you can
do this with Gnat, but I think we need a solution for all compilers).

Dale

Re: Y2K Issues

[Samuel Mize]

In article <dale-2910981230010001@dale.ppp.cs.rmit.edu.au>,
Dale Stanbrough <dale@cs.rmit.edu.au> wrote:
>Don't we just need to support dates in the same way we support time,
>i.e. have a universal date (like GMT), and then supply localisation
>routines which allow different locations to convert from/to local 
>calendars...
>
>   package Calendar;
>   package Calendar.Monotonic;
>   package Calendar.Monotonic.Gregorian
>   package Calendar.Monotonic.Julian;    

Sounds reasonable.

Package Calendar won't handle Genealogy, History, Astronomy -- what's
WRONG with its design?

NOTHING!

It was intended to be a representation of "now" and nearby times
in embedded systems.  We don't need a compiler-based standard
for time, we just need some commonly-distributed packages that
implement useful versions of time, depending on what you're doing.

Are you really planning to write a delay statement that will
show up in a geological time frame?

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

Re: Y2K Issues

[Mark A Biggar]

Dale Stanbrough wrote:
 
>    package Calendar;
>    package Calendar.Monotonic;
>    package Calendar.Monotonic.Gregorian
>    package Calendar.Monotonic.Julian;
> 
> etc.
> Does making these children of (Ada.)Calendar aren't we locking it into
> a framework where people can't extend the hierachy because "only compiler
> developers are allowed to extend the Ada hierachy"? (yes, i know you can
> do this with Gnat, but I think we need a solution for all compilers).

Read the LRM carefully, it only disallows direct childern of package Ada,
grandchildern and so on ARE allowed.  So, all the above packages are legal
and can be written and supplied by anyone.  

--
Mark Biggar
mark.a.biggar@lmco.com

Re: Y2K Issues

[Tucker Taft]

Dale Stanbrough (dale@cs.rmit.edu.au) wrote:

: ...
: Don't we just need to support dates in the same way we support time,
: i.e. have a universal date (like GMT), and then supply localisation
: routines which allow different locations to convert from/to local 
: calendars...

:    package Calendar;
:    package Calendar.Monotonic;
:    package Calendar.Monotonic.Gregorian
:    package Calendar.Monotonic.Julian;    

I presume you really mean Ada.Calendar...

: etc.
: Does making these children of (Ada.)Calendar aren't we locking it into
: a framework where people can't extend the hierachy because "only compiler
: developers are allowed to extend the Ada hierachy"? 

Users *are* allowed to add grandchildren to package Ada.
They may not add "direct" children to package Ada (nor may vendors,
for that matter) -- see RM95 A.2(4).

: ... (yes, i know you can
: do this with Gnat, but I think we need a solution for all compilers).

This is not GNAT-specific.

: Dale

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company

Re: Y2K Issues

[dewar]

In article <F1LGL1.B6F.0.-s@inmet.camb.inmet.com>,
  stt@houdini.camb.inmet.com (Tucker Taft) wrote:
> Users *are* allowed to add grandchildren to package Ada.
> They may not add "direct" children to package Ada (nor may vendors,
> for that matter) -- see RM95 A.2(4).

I find this a very odd claim. In RM A(4) we have

                         Implementation Permissions

4   The implementation may restrict the replacement of language-defined
compilation units.  The implementation may restrict children of
language-defined library units (other than Standard).

This sure says to me that an implementation may restrict the addition of
children of Ada.Calendar, and in fact GNAT does NOT permit users to add
children to this package, despite Dale's claim. Yes, of course you can
always decide you are a GNAT implementor and change the compiler, using
internal implementor options, but users may not add such children.

Ada.Calendar most certainly is a language-defined library unit!

The legality rule that Tuck refers to is:

                               Legality Rules

4   In the standard mode, it is illegal to compile a child of package Ada.

which means that no compiler should allow you to add children to Ada. But
the paragraph I quoted above clearly allows a compiler to forbid the addition
of children of packages in Ada unless I am really missing something!

Robert Dewar
Ada Core Technologies

P.S. Why don't we want customers adding grandchildren of Ada -- simple, they
would potentially depend on internal private parts of the implementation of
these packages which we feel free to change without notice at any time!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Y2K Issues

[Tucker Taft]

dewar@gnat.com wrote:

: In article <F1LGL1.B6F.0.-s@inmet.camb.inmet.com>,
:   stt@houdini.camb.inmet.com (Tucker Taft) wrote:
: > Users *are* allowed to add grandchildren to package Ada.
: > They may not add "direct" children to package Ada (nor may vendors,
: > for that matter) -- see RM95 A.2(4).

: I find this a very odd claim. In RM A(4) we have

:                          Implementation Permissions

: 4   The implementation may restrict the replacement of language-defined
: compilation units.  The implementation may restrict children of
: language-defined library units (other than Standard).

: ... But
: the paragraph I quoted above clearly allows a compiler to forbid the addition
: of children of packages in Ada unless I am really missing something!

Good point, Robert.

So, some compilers might allow user-defined grandchildren of Ada, while
others might not, so it is not a portable capability.  Even if it 
were allowed by all relevant compilers, as Robert points out below, 
the actual code of the (grand)child would probably not be portable,
since presumably it would depend on implementation-specific
private types.  

(FWIW, from my point of view, the fact that the code for such 
grand-children is likely to be implementation-specific doesn't seem like 
enough of a reason to disallow them, since the whole point may be to provide 
a stable interface to some additional functionality via a 
grand-child, recognizing that the implementation of the functionality may 
need to be revised when porting to a new compiler or new release.  Clearly
the "caveat emptor" is critical here.)

: Robert Dewar
: Ada Core Technologies

: P.S. Why don't we want customers adding grandchildren of Ada -- simple, they
: would potentially depend on internal private parts of the implementation of
: these packages which we feel free to change without notice at any time!

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company

Re: Y2K Issues

[dennison]

In article <F1Lt90.HEx.0.-s@inmet.camb.inmet.com>,
  stt@houdini.camb.inmet.com (Tucker Taft) wrote:

> (FWIW, from my point of view, the fact that the code for such
> grand-children is likely to be implementation-specific doesn't seem like
> enough of a reason to disallow them, since the whole point may be to provide
> a stable interface to some additional functionality via a
> grand-child, recognizing that the implementation of the functionality may
> need to be revised when porting to a new compiler or new release.  Clearly
> the "caveat emptor" is critical here.)

It sure would have helped me a lot a few days ago if I could have made my
package Ada.Real_Time.Float_Conversions, instead of
Real_Time_Float_Conversions. Apparently Green Hills decided to disallow
children of their pacakges. My implementation of this package is *still*
dependent on their implementation of Ada.Real_Time.Time_Span. Its just that I
was forced to do Unchecked_Conversions to accomplish it. (I feel so dirty!)
And now when their implementation does change, I might not notice until
runtime. If they'd let me make a child package I could have gotten a compile
error when the implemetation changes.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Y2K Issues

[dewarr]

In article <71ckkt$n4a$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> In article <F1Lt90.HEx.0.-s@inmet.camb.inmet.com>,
>   stt@houdini.camb.inmet.com (Tucker Taft) wrote:
>
> > (FWIW, from my point of view, the fact that the code for such
> > grand-children is likely to be implementation-specific doesn't seem like
> > enough of a reason to disallow them, since the whole point may be to
provide
> > a stable interface to some additional functionality via a
> > grand-child, recognizing that the implementation of the functionality may
> > need to be revised when porting to a new compiler or new release.  Clearly
> > the "caveat emptor" is critical here.)
>
> It sure would have helped me a lot a few days ago if I could have made my
> package Ada.Real_Time.Float_Conversions, instead of
> Real_Time_Float_Conversions. Apparently Green Hills decided to disallow
> children of their pacakges. My implementation of this package is *still*
> dependent on their implementation of Ada.Real_Time.Time_Span. Its just that I
> was forced to do Unchecked_Conversions to accomplish it. (I feel so dirty!)
> And now when their implementation does change, I might not notice until
> runtime. If they'd let me make a child package I could have gotten a compile
> error when the implemetation changes.


You cannot count on having got a compile error if the implementation changes.
You might or might not. Just as your unchecked conversion might have got a
warning if the sizes were different (I assume your compiler provides this
important warning).

If using unchecked_conversion makes you feel dirty, then compiling
grandchildren of Ada that depend on private data structures should make
you equally queasy, if not more so!

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Y2K Issues

[dennison]

In article <71dott$cm0$1@nnrp1.dejanews.com>,
  dewarr@my-dejanews.com wrote:
> In article <71ckkt$n4a$1@nnrp1.dejanews.com>,
>   dennison@telepath.com wrote:
> > children of their pacakges. My implementation of this package is *still*
> > dependent on their implementation of Ada.Real_Time.Time_Span. Its just that
I
> > was forced to do Unchecked_Conversions to accomplish it. (I feel so dirty!)
> > And now when their implementation does change, I might not notice until
> > runtime. If they'd let me make a child package I could have gotten a compile
> > error when the implemetation changes.
>
> You cannot count on having got a compile error if the implementation changes.
> You might or might not. Just as your unchecked conversion might have got a
> warning if the sizes were different (I assume your compiler provides this

Given their implementation of Ada.Real_Time.Time_Span, it is a simple matter
to write a program that will convert it into a Float, and will survive minor
type changes with only a recompile (using 'first and 'last on the field's
type). Yes, they could hose me by dropping the interger subtypes altogether.
But the way I had to do it with Unchecked_Conversion *any* range change will
hose me.

But perhaps this isn't too good of an example. I was forced into this unsafe
situation by a compiler bug in Ada.Real_Time.To_Time_Span. (The language
definition bug of not providing a To_Time_Span for Float was only a secondary
consideration.) When the next compiler version comes out it'll probably have
the problem fixed, and I'll need to recode things anyway. Providing this
facility because of the possible need to work-around compiler bugs seems a
bit too pessimistic.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Y2K Issues

[Dale Stanbrough]

Robert Dewar wrote:

" and in fact GNAT does NOT permit users to add
  children to this package, despite Dale's claim. Yes, of course you can
  always decide you are a GNAT implementor and change the compiler, using
  internal implementor options, but users may not add such children."


This is of course what I was referring to (allowing _anyone_ to be a 
compiler implementor). I remember you making this comment two or three
years ago.


Dale

Re: Y2K Issues

[Matthew Heaney]

dewar@gnat.com writes:

> P.S. Why don't we want customers adding grandchildren of Ada -- simple, they
> would potentially depend on internal private parts of the implementation of
> these packages which we feel free to change without notice at any time!

But isn't that the whole point adding the (grand)child - to get at the
underlying representation of predefined types?

If I add a child to Ada.Calendar, and the vendor changes the internal
details of that package, then it's my problem!

Re: Y2K Issues

[dewar]

In article <m3vhl224uy.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:
> dewar@gnat.com writes:
>
> > P.S. Why don't we want customers adding grandchildren of Ada -- simple,
they
> > would potentially depend on internal private parts of the implementation of
> > these packages which we feel free to change without notice at any time!
>
> But isn't that the whole point adding the (grand)child - to get at the
> underlying representation of predefined types?
>
> If I add a child to Ada.Calendar, and the vendor changes the internal
> details of that package, then it's my problem!


If you are a manager, and one of your (incompetent) programmers introduces
dependencies on internal data structures of the compiler, which change without
warning with a new version of the compiler, so that your compiler no longer
works, who do you blame? Very often it is the vendor who gets the blame for
introducing incompatible changes. Yes, of course you can point out from a
legal point of view that it was the customer's fault, but that does not help
much. After all, when Intel produced the 80188 and stole one of the "reserved"
interrupts that was (mis)used by DOS, it is true that Intel was in the right,
but the bottom line was that the PC Junior, and other DOS based machines,
were not interested in this chip as a result.

We obviously can't stop anyone changing the compiler if they want to, and
introducing problems of this type, but we do like to make it clear to a
user that they are taking a potentially serious step in accessing internals
of the implementation, in terms of future compatibility. That is why we have
the -gnatg switch, which is to be used ONLY by GNAT implementors. Of course
users are free to use this switch (which among many other somewhat peculiar
things, allows you to add grandchildren to Ada -- if you follow the strict
style rules that are required). But as far as we are concerned, from an
official point of view, users should not use -gnatg.

By using a special switch, rather than casually allowing grandchildren of
Ada to be compiled and recompiled, we point out to the user that this is
non-standard Ada that may be incompatible with future compiler versions.

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Y2K Issues

[adam]

In article <36365724.EF1CC215@maths.unine.ch>,
  Gautier de Montmollin <gautier.demontmollin@maths.unine.ch> wrote:

> Someone in an hydrological bureau had the same shock today reading that
> LRM topic in AdaHelp, but because of the 1901 problem: many archived time
> series begin before 1901... (hydrology, geography etc.) => Calendar is
> useless for it ! One has to program a Calendar bis. It's not that
> the formulas for this purpose don't exist or are too complicated...
> And what to think about astronomical calculations / previsions ?...

I'm not sure exactly what you mean by astronomical calculations.  However, if
you have computed that some star was formed three billion years ago on
exactly March 18th, at 2:29:17 GMT, and you need to know what day of the week
the star was formed on, I suppose you could write your own version of
Calendar to perform the needed computations.

				-- Adam

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Y2K Issues

[Gautier.DeMontmollin]

> I'm not sure exactly what you mean by astronomical calculations.  However, if
> you have computed that some star was formed three billion years ago on
> exactly March 18th, at 2:29:17 GMT, and you need to know what day of the week
> the star was formed on, I suppose you could write your own version of
> Calendar to perform the needed computations.

What a disappointment. I was about to use Ada.Calendar to determine the
day of the week the Big Bang occured - and if possible the GMT time it
occured, too. 

-- 
Gautier