Y2K Issues 
Author Message
 Y2K Issues

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

  vcard.vcf
< 1K Download


Fri, 06 Apr 2001 03:00:00 GMT  
 Y2K Issues

Quote:

> 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



Fri, 06 Apr 2001 03:00:00 GMT  
 Y2K Issues

: ...
: 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




Fri, 06 Apr 2001 03:00:00 GMT  
 Y2K Issues


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

> 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?

This subtype range restriction simplifies recognizing leap years.  ForYear:
Year_Number;, Year is a leap year if and only if (Year mod 4) = 0.
This simple rule is violated for 1900 and 2100, which are not leap years.

The tasking or event-scheduling processing for most applications should
do fine with this restriction.  If your need for date handling is more
extensive (such as for a database application), you are free to develop
your own type and supporting subprograms.

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
to have a range of 2001 .. 2399 (399 years instead of only 199 years),
with the slight complication in leap year determination as:  Year is a
leap year if and only if (Year mod 4) = 0 and (Year mod 100) /= 0.

[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).]

Quote:
> Thanks,


>   Software Engineering Instructor
>   Raytheon Systems Company

Howard W. LUDWIG


Fri, 06 Apr 2001 03:00:00 GMT  
 Y2K Issues

Quote:

> 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)

Quote:
> 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.

Quote:
> 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



Fri, 06 Apr 2001 03:00:00 GMT  
 Y2K Issues

 > [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...



Sat, 07 Apr 2001 03:00:00 GMT  
 Y2K Issues

Quote:

> 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



Sat, 07 Apr 2001 03:00:00 GMT  
 Y2K Issues


<snip>

Quote:
>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



Mon, 09 Apr 2001 03:00:00 GMT  
 Y2K Issues

Quote:
>> 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.


Tue, 10 Apr 2001 03:00:00 GMT  
 Y2K Issues

 > > 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...



Tue, 10 Apr 2001 03:00:00 GMT  
 Y2K Issues

Quote:





>> <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. :-)

I recall seeing an article several years back that was talking about a
satellite that was essentially a big huge chunk of metal with mirrors on it.
The idea was that they wanted something with a fair amount of mass placed in
a very stable orbit off of which they could bounce lasers to make precise
measurements for geological purposes - or as you suggest - keep track of
continental drift. Since the satellite had no battery powered gonculators or
fuel driven fragistats on board, the only real limitation to its life span
was how long it would stay in its proper orbit - which I could image to be
8000 years. But then again, without any computerized whozits on board, it
wouldn't likely have much of a Y2K problem, would it? ;-)

I'd be interested to hear about any satellite - operational or planned -
which had any non-trivial electrical or mechanical apparatus which was
expected to operate for 8000 years. And I'd like to know if that was just an
accidental byproduct or if it was a design requirement.

MDC
Marin D. Condic
Real Time & Embedded Systems
United Technologies, Pratt & Whitney
Government Engines & Space Propulsion
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669

"We don't like their sound, and guitar music is on the way out."
    --  Decca Recording Co. rejecting the Beatles, 1962.



Tue, 10 Apr 2001 03:00:00 GMT  
 Y2K Issues


[snip]

Quote:

>[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.


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



Thu, 12 Apr 2001 02:00:00 GMT  
 
 [ 65 post ]  Go to page: [1] [2] [3] [4] [5]

 Relevant Pages 

1. Clarion 2.1 Y2K Issue patchy2k.exe no work!!

2. Y2K Issues in CDD for DOS

3. Any Y2K issues for CPD v2.1

4. Y2k issue

5. Need Urgent Help- Y2K issue

6. New Y2k Issue

7. Y2k Issue

8. OT: OS/390 Y2K issue

9. Only one real Y2K issue left

10. Simple question on the Y2K issue

11. cgi.tcl y2k issue(?)

12. Query -- Y2K issues in "legacy" Tcl/Tk (not in FAQ)

 

 
Powered by phpBB® Forum Software