Software Engineering News Brief

Software Engineering News Brief

[Software Engineering News]

Software Engineering News Brief
Week Ending 11/1/96.

***************************************************
ARTICLE CODE KEY:

Articles contained in the Software Engineering News Brief are classified 
according to the four major areas covered by the Software Engineering 
Information Center (SEIC).  They are:

ADA:  Ada and Ada 95 related issues.
REUSE:  Software reuse related issues.
DII:  Defense Information Infrastructure related issues.
COE:  Common Operating Environment related issues.

********************************
AJPO SAYS ADA'S FUTURE IS SOLID

Even if Ada loses its preferred status for all but military weapons 
systems, the language won't die, said Dr. Charles Engle, chief of the 
Defense Department's Ada Joint Program Office.

AJPO, which promotes the DoD-funded language, plans to win greater 
acceptance through education, Engle said.  This year, all freshman at 
the U.S. Military Academy and the Air Force Academy are required to take 
Ada 95 programming.  AJPO has won commitments to Ada 95 from 17 DoD program 
managers, through incentives that include free training and financial 
assistance with tools and bindings.

Engle said that a National Research Council review of DoD's Ada policy, 
due October 31, likely will recommend that Ada remain the preferred 
language for certain command-and-control systems.  He expects the report 
to recommend using commercial applications elsewhere.

TOPIC:  ADA

SOURCE:  Government Computer News v15(25), Oct. 7, 1996, p.3.

*******************************
YEAR 2000  NO PROBLEM FOR ADA

Ada developers who've been scorned by the C/C++ camp might be laughing 
all the way to the year 2000.

Ada applications aren't likely to fail any time between now and January 1, 
2000, or beyond, for the simple reason that Ada doesn't let programmers 
represent dates in two-digit shorthand.

"There's no problem with Ada," said Jacques Brygier, marketing director 
for Thompson Software Products.  "The language has been defined in a way 
that you cannot make this kind of mistake."  

According to Dr. Charles Engle, chief of the Ada Joint Program Office, the 
Ada language itself has built-in dates from 1901 to 2099, thus eliminating 
the 2000 problem.

TOPIC: ADA

SOURCE:  Olsen, Florence.  "Ada sails smoothly into 2000," Government 
Computer News v15(25), Oct. 7, 1996, p. 33.  

*************************************

DCE INCORPORATED INTO WORLD WIDE WEB CLIENTS AND SERVERS

Government Computer News reports that vendors have announced the first 
products incorporating the Distributed Computed Environment (DCE) into 
World Wide Web clients and servers.

IBM's DCE-based "DFS Web" and Transarc Corporation's DCE "DFS Light" 
incorporate DCE server software and protocols for making Web-type 
environments practical for secure intranets.  They will deal with a 
"security problem that the Web up to this point has not been able to 
solve," said Ron Galvin, a consultant with Keane Federal Systems in 
Columbia, MD.

The products, priced at about $75 for client software and at about $1500 
for the server, will be shipped this Fall and in early 1997.

TOPIC:  DII, COE

SOURCE:  Olsen, Florence.  "DCE services start to appear in Web clients 
and servers," Government Computer News v15(27), Oct. 21, 1996, p. 36.
  
*******************************************

DOD SIMULATION STANDARDS PROMOTE REUSE

The Defense Department has established a new High Level Architecture 
(HLA) in order to attain a higher return on its investment in modeling 
and simulation technology.  This new technical architecture, to which all 
present and future simulation projects must conform, lays out basic rules 
of behavior simulation that programs should follow and defines the 
interfaces through which independently developed programs can interact.

DoD believes that HLA will make it easier to get more use and, 
importantly, more reuse out of its simulation programs.  By providing 
interoperability, the new architecture will allow the quick "federation" 
of simulation programs by tying together programs developed through 
different services.  Joint programs are a priority because man DoD 
missions require joint service participation.

An order signed last month by the under-secretary of Defense for 
acquisition and technology requires all future simulation programs to 
comply with HLA and all existing programs to be brought into compliance 
or phased out by the first day of fiscal year 2001.

TOPIC:  REUSE

SOURCE:  Monroe, John Stein.  "DoD adopts simulation standards," Federal 
Computer Week v10(30), October 7, 1996, p. 10, 16.

*******************************************************

The Defense Information Systems Agency (DISA) Software Engineering 
Information Center (SEIC) "Software Engineering News Brief" is a  
compilation of summaries from software engineering-related   
articles in trade magazines, newsletters and press releases. The DISA 
SEIC welcomes suggestions for and pointers to software
engineering-related articles.  Contact the DISA SEIC at:    
    
info@sw-eng.falls-church.va.us   
    
To subscribe to the "Software Engineering News Brief" electronic 
mailing     
list, send a message to:    
        listproc@sw-eng.falls-church.va.us    
In the body of the message, write:    
        subscribe newslist <your name>    
To unsubscribe, write:    
        unsubscribe newslist    
No signatures please.

Re: Software Engineering News Brief

[Adam Beneschan]

seic@sw-eng.falls-church.va.us (Software Engineering News) writes:

 >*******************************
 >YEAR 2000  NO PROBLEM FOR ADA
 >
 >Ada developers who've been scorned by the C/C++ camp might be laughing 
 >all the way to the year 2000.
 >
 >Ada applications aren't likely to fail any time between now and January 1, 
 >2000, or beyond, for the simple reason that Ada doesn't let programmers 
 >represent dates in two-digit shorthand.
 >
 >"There's no problem with Ada," said Jacques Brygier, marketing director 
 >for Thompson Software Products.  "The language has been defined in a way 
 >that you cannot make this kind of mistake."  
 >
 >According to Dr. Charles Engle, chief of the Ada Joint Program Office, the 
 >Ada language itself has built-in dates from 1901 to 2099, thus eliminating 
 >the 2000 problem.
 >
 >TOPIC: ADA
 >
 >SOURCE:  Olsen, Florence.  "Ada sails smoothly into 2000," Government 
 >Computer News v15(25), Oct. 7, 1996, p. 33.  
 >
 >*************************************

Ada has a number of advantages over other languages, so I hope no one
trying to advocate the language resorts to a lame reason like this
one.  The Year 2000 problem is a software design issue, not a language
issue.  I think that programmers in recent years have been aware that
the millenium is looming, more than they were 25-30 years ago, so any
program designed these days will take the year 2000 into account.
Sure, other languages like C don't have standard library routines to
handle dates defined in the language definition, but it's no problem
to put your own together.  So I don't see how Year 2000 issues give us
any particular reason to crow about Ada.  (Or to insult C/C++ in the
process.  I'm willing to bet that the vast majority of programs with a
Year 2000 problem are COBOL, RPG, or other older languages, not C and
definitely not C++.)

                                -- Adam

Re: Software Engineering News Brief

[tmoran]

>>Ada applications aren't likely to fail any time between now and January 1,
>>2000, or beyond, for the simple reason that Ada doesn't let programmers
>>represent dates in two-digit shorthand.
>
>Seems rather restrictive.
  It's also incorrect.  Ada, like any other general purpose programming
language, of course lets programmers encode dates any way they please.
Ada *does* have a standard Calendar.Time type with a Year from 1901
through 2099, which any product calling itself a validated Ada compiler
is required to support.  So programmers will usually find it simpler to
use the standard than to 'roll their own' internal encoding.  The
standard says nothing about external, human readable input/output
formats, however, and as an international standard it could hardly demand
conformance to, say, "MM/DD/YY" or "Fifth Day of November, Year of Our
Lord Nineteen Hundred and Ninety Six".  ;)

Re: Software Engineering News Brief

[jimgregg]

>The standard says nothing about external, human readable 
>input/output formats, however, and as an international 
>standard it could hardly demand conformance to, say, 
>"MM/DD/YY" or "Fifth Day of November, Year of Our
>Lord Nineteen Hundred and Ninety Six".  ;)

So if you are using a package that provides utility subprograms
for converting between Calendar.Time and "mmddyy", check the
implementation.  It may use 1900 in conversion expressions.

I have a package called DATES, provided by a compiler vendor, 
that has this problem.  

Jim Gregg
Software Compositions

Re: Software Engineering News Brief

[Robert Dewar]

tmoran said

"  It's also incorrect.  Ada, like any other general purpose programming
language, of course lets programmers encode dates any way they please.
Ada *does* have a standard Calendar.Time type with a Year from 1901
through 2099, which any product calling itself a validated Ada compiler
is required to support.  So programmers will usually find it simpler to
use the standard than to 'roll their own' internal encoding.  The
standard says nothing about external, human readable input/output
formats, however, and as an international standard it could hardly demand
conformance to, say, "MM/DD/YY" or "Fifth Day of November, Year of Our
Lord Nineteen Hundred and Ninety Six".  ;)"


A specific example is that in GNAT, the ali files use time stamps that have
a YY representation for the year. 

It is an interesting indication of how people are sensitized to the year
2000 feature that now two people evaluating GNAT have worried that this
means that GNAT has a year 2000 problem (it does not :-)

Re: Software Engineering News Brief

[David Bradley]

seic@sw-eng.falls-church.va.us (Software Engineering News) wrote:

>Ada applications aren't likely to fail any time between now and January 1, 
>2000, or beyond, for the simple reason that Ada doesn't let programmers 
>represent dates in two-digit shorthand.

Seems rather restrictive.  So you're saying that if I decide to code
up a julean type date and use only the last two digits of the year,
that's impossible to do in Ada?  So as a user, I have to always type
the four digit year?  This is unecessary in most cases.  As the first
two digits can be determined with some intelligent logic.

--------------------------------------------
David Bradley         davidb@datalytics.com
Software Engineer
Datalytics, Inc.      http://www.datalytics.com

Re: Software Engineering News Brief

[Larry Kilgallen]

In article <32805050.417820504@news>, davidb@datalytics.com (David Bradley) writes:
> seic@sw-eng.falls-church.va.us (Software Engineering News) wrote:
> 
>>Ada applications aren't likely to fail any time between now and January 1, 
>>2000, or beyond, for the simple reason that Ada doesn't let programmers 
>>represent dates in two-digit shorthand.
> 
> Seems rather restrictive.  So you're saying that if I decide to code
> up a julean type date and use only the last two digits of the year,
> that's impossible to do in Ada?  So as a user, I have to always type
> the four digit year?  This is unecessary in most cases.  As the first
> two digits can be determined with some intelligent logic.

No, Ada, like many other environments tries to lead one in the
direction of avoiding the century problem, but one can always
choose not to follow.  As a matter of fact, one can even encode
years using only a single digit, but that is more hazardous as
there is increased chance of being at the same employer when
everything falls apart.

Larry Kilgallen

Re: Software Engineering News Brief

[Steve Jones - JON]

Larry Kilgallen wrote:
> 
> In article <32805050.417820504@news>, davidb@datalytics.com (David Bradley) writes:
> > seic@sw-eng.falls-church.va.us (Software Engineering News) wrote:
> 
> No, Ada, like many other environments tries to lead one in the
> direction of avoiding the century problem, but one can always
> choose not to follow.  As a matter of fact, one can even encode
> years using only a single digit, but that is more hazardous as
> there is increased chance of being at the same employer when
> everything falls apart.
> 
> Larry Kilgallen


But remember you can always blame one of the people who _has_ left,
and produce your fix in 0 seconds flat to the amazement of
management :-)

Steve Jones

PS Ada makes it harder to programme badly and makes bad programming
   easier to spot and to correct IME.

Re: Software Engineering News Brief

[Tom Reid]

tmoran@bix.com wrote:
> 
> >>Ada applications aren't likely to fail any time between now and January 1,
> >>2000, or beyond, for the simple reason that Ada doesn't let programmers
> >>represent dates in two-digit shorthand.
> >
> >Seems rather restrictive.
>   It's also incorrect.  Ada, like any other general purpose programming
> language, of course lets programmers encode dates any way they please.
> Ada *does* have a standard Calendar.Time type with a Year from 1901
> through 2099, which any product calling itself a validated Ada compiler

Let me see if I have this right.  Ada does not have a year 2000 problem
but it does have a year 2100 problem (not that this will affect any of
us).

Anyone know why they didn't make it a span of 255 years and not waste
digits?

> is required to support.  So programmers will usually find it simpler to
> use the standard than to 'roll their own' internal encoding.  The
> standard says nothing about external, human readable input/output
> formats, however, and as an international standard it could hardly demand
> conformance to, say, "MM/DD/YY" or "Fifth Day of November, Year of Our
> Lord Nineteen Hundred and Ninety Six".  ;)

Tom Reid, treid@primenet.com

Re: Software Engineering News Brief

[John Cosby]

Software Engineering News wrote:
> 
> Software Engineering News Brief
> Week Ending 11/1/96.
> *******************************
> YEAR 2000  NO PROBLEM FOR ADA
> 
> Ada developers who've been scorned by the C/C++ camp might be laughing
> all the way to the year 2000.
> 
> Ada applications aren't likely to fail any time between now and January 1,
> 2000, or beyond, for the simple reason that Ada doesn't let programmers
> represent dates in two-digit shorthand.
> 
> "There's no problem with Ada," said Jacques Brygier, marketing director
> for Thompson Software Products.  "The language has been defined in a way
> that you cannot make this kind of mistake."
> 
> According to Dr. Charles Engle, chief of the Ada Joint Program Office, the
> Ada language itself has built-in dates from 1901 to 2099, thus eliminating
> the 2000 problem.

Ah, but do the applications programmed in Ada use this?

I worked on a system for a branch of the military where Ada was used to
drive a database - and the tables contain 2-digit year fields.  We
pointed
this out, we went and said it very clear, we went and shouted in their
ears -
and the military folk said we had to leave it that way, for
compatibility 
with their existing systems.  We were told to assume dates between 00
and 49
were in the 2000s.

The language can't overcome obstinance on the part of the customer.
-- 
John Cosby                    SAIC Orlando               
John.D.Cosby@cpmx.saic.com    (407) 282-6700 x216

Re: Software Engineering News Brief

[Ed Falis]

David,

The predefined "date" type keeps 4 digits (actually a subrange of
4 digit dates covering roughly a coupl ehundred years).

If you want to use something like a julian date, you'd just define
your own type and use it the way you wanted to.

Re: Software Engineering News Brief

[Norman H. Cohen]

Tom Reid wrote:

> Let me see if I have this right.  Ada does not have a year 2000 problem
> but it does have a year 2100 problem (not that this will affect any of
> us).
> 
> Anyone know why they didn't make it a span of 255 years and not waste
> digits?

They had a different microoptimization in mind :-).  Years range from
1901 to 2099 in the standard Ada calendar package to slightly simplify
the determination of whether a given year is a leap year.  (Within that
range a year is a leap year if and only if it is divisible by four.  In
contrast, the years 1900 and 2100 are both divisible by four, but are
not leap years.)

(Your comment about not wasting bits seems to presume that time is
represented with a byte devoted to representing the year.  Other
representations are possible, e.g. representing a time in terms of the
number of seconds elapsed since the start of 1970.)

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: Software Engineering News Brief

[Robert Dewar]

Tom Reid says

"Anyone know why they didn't make it a span of 255 years and not waste
digits?"

First, there is nothing special about 255 years, since typically
representations of time don
't work that way in any case (e.g. a typical representation of time is
duration wrt some reference point).

Second, since time is a private type, it is unlikely that any Ada programs
will in fact have a 2100 problem which cannot be trivially corrected
(no doubt on the 512-bit machines of the day, large ranges will not be
a problem).

Third, the range given has one nice characteristic, no special handling of
leap years is needed (2100 is not a leap year).
I will guess in fact that the issue in 2100 will precisely be problems
on Feb 29th :-)

Re: Software Engineering News Brief

[Stefan.Landherr]

Robert Dewar wrote:
> A specific example is that in GNAT, the ali files use time stamps that have
> a YY representation for the year.
> 
> It is an interesting indication of how people are sensitized to the year
> 2000 feature that now two people evaluating GNAT have worried that this
> means that GNAT has a year 2000 problem (it does not :-)


Does any part of the GNAT toolset ever need to sort these files in
chronological order or perform any other form of timestamp comparison ?

--
--
--
--
--
--

Re: Software Engineering News Brief

[tmoran]

>  I don't believe there is any requirement to *limit* years to 1900-2099,
>rather there *is* a portability requirement to allow *at least* that range.
   I just looked this up and it needs correction: the system should be
able to raise an exception when the year is outside 1901 through 2099,
or the month is outside 1 through 12, etc.  If the vendor wants to allow
the programmer to relax these rules, he'll have to allow the programmer
to do it via a pragma, compilation time switch, or some such thing, and,
of course, the vendor should then document just what his compiler allows.

Re: Software Engineering News Brief

[Robert Dewar]

tmoran says

"  I don't believe there is any requirement to *limit* years to 1900-2099,
rather there *is* a portability requirement to allow *at least* that range."

Which just goes to show that it is better to read the RM than rely on what
you believe:

11    subtype Year_Number  is Integer range 1901 ..  2099;

there is no allowed implementation dependent variation in this type
declaration!

Re: Software Engineering News Brief

[Robert Dewar]

tmoran says

"   I just looked this up and it needs correction: the system should be
able to raise an exception when the year is outside 1901 through 2099,
or the month is outside 1 through 12, etc.  If the vendor wants to allow
the programmer to relax these rules, he'll have to allow the programmer
to do it via a pragma, compilation time switch, or some such thing, and,
of course, the vendor should then document just what his compiler allows."

Well of course you can do anything with a compiler switch, even recognize
C++ instead of Ada :-)

However, extending the range of Year_Number with a switch would be a highly
inappropriate language extension in my view. It would be much better to 
provide an alternative package, e.g. Extended_Calendar, which looked similar
to Calendar, but provided an extended period of coverage.

Re: Software Engineering News Brief

[caip.rutgers.edu!halasz]

In article <55rmsc$2ee$1@shade.twinsun.com>, eggert@twinsun.com (Paul Eggert) writes
> Well, that's true as far as it goes, but it
> turns out that several Solaris applications (SCCS and xterm, for example)
> _do_ have year-2000 problems because the application developers saw fit
> to take the year modulo 100, or subtract 1900 from the year, or some
> such nonsense.

The latter is not nonsens, for if
	x < y
then
	x - 1900 < y - 1900
--there is nothing wrong with that.  But this
	printf("%02d", y - 1900);
amounts to year modulo 100 (if "y >= 0"), not year less 1900.  To wit,
by itself subtracting 1900 is no problem, but one who did is eazily led
astray into the real trap.

Incidentally, the century-turn is not enough grounds for to drop the
convenient abbreviation of uzing only the last twain digits of the
year-numeral; it is grounds for care.  In a system that I workd on, such
2-digit numerals were permitted in data-entry, in text-formd datafiles,
but the meaning of it depended on a configuration variable.  If this was,
o, 1940, 2-digit year-numerals span 1940-2039.  That is, if the short
numeral is less than the (0-based) remainder of dividing the variable by
100 it stands for the year numberd 2000 (100+variable-remainder) greater,
otherwize for the year numberd 1900 (variable-remainder) greater.

One can make SCCS work on by either taking the year in the file to be
1900 less than the real number--in this case, 2000 Jan 12 is "100/01/12",
or installing sum such scheme as aforesaid in "delta", "get", "prs", ...,
maibe make it a new flag in the history-file itself, & if not there it is
taken for 1970 (an important year for Unix).

Re: Software Engineering News Brief

[Robert I. Eachus]

In article <3280BAFA.1B2F@email.mot.com> Tom Reid <tom_reid-sc661c@email.mot.com> writes:

  > Anyone know why they didn't make it a span of 255 years and not waste
  > digits?

    Because 1900 was not a leap year, and 2100 will not be a leap
year, but 2000 will be a leap year.  So 1901 to 2099 is the longest
span possible without requiring implementors to include a leap year
rule that has never been used in practice.  (The rule that years
divisible by 400 are leap years, in spite of the rule about years
divisible by 100.)

    I'm sure that the next version of Ada will support a longer range
of dates, but I doubt that it will go too far back.  In fact, there
are areas where Gregorian dates from the beginning of this century are
nonsense, since Greece and Russia among others were still using the
Julian calendar in 1901.

--

					Robert I. Eachus

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

Re: Software Engineering News Brief

[Paul Eggert]

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

> 1901 to 2099 is the longest
> span possible without requiring implementors to include a leap year
> rule that has never been used in practice.

Actually, many kinds of applications require support for dates outside
that range; it was shortsighted of the Ada standard-writers to prohibit
implementations from having better standard date support than that.

>    I'm sure that the next version of Ada will support a longer range
>of dates, but I doubt that it will go too far back.  In fact, there
>are areas where Gregorian dates from the beginning of this century are
>nonsense

... which is why the next version of Ada should support Gregorian dates
all the way back to at least the year 1, if not before.  Trying to
match the historical introduction of the Gregorian calendar
leads to severe politico-technical problems.  For an example of this
see my May 1995 comp.risks article about Sybase's historically naive
practice of arbitrarily rejecting Gregorian dates before 1753.

Re: Software Engineering News Brief

[tmoran]

>"   I just looked this up and it needs correction: the system should be
>able to raise an exception when the year is outside 1901 through 2099,
>or the month is outside 1 through 12, etc.  If the vendor wants to allow
>the programmer to relax these rules, he'll have to allow the programmer
>to do it via a pragma, compilation time switch, or some such thing, and,
>of course, the vendor should then document just what his compiler allows."
>
>However, extending the range of Year_Number with a switch would be a highly
>inappropriate language extension in my view. It would be much better to
>provide an alternative package, e.g. Extended_Calendar, which looked similar
>to Calendar, but provided an extended period of coverage.
  Extending the range of Year_Number with a compiler switch might or might
not be a good idea, but turning off constraint checking either locally
on calls to Split, Time_Of, "+", "-" etc with a Pragma, or globally with
a compiler switch, is what I had in mind.  (Obviously Split et al must be
coded to properly handle such shenanigans, but we're assuming here that
a vendor is specifically trying to allow extension of the usual range.)

Re: Software Engineering News Brief

[Robert Dewar]

tmoran says

"  Extending the range of Year_Number with a compiler switch might or might
not be a good idea, but turning off constraint checking either locally
on calls to Split, Time_Of, "+", "-" etc with a Pragma, or globally with
a compiler switch, is what I had in mind.  (Obviously Split et al must be
coded to properly handle such shenanigans, but we're assuming here that
a vendor is specifically trying to allow extension of the usual range.)"


From bad to horrible :-)

The idea of encouraging people to write erroneous programs is truly a bad
one. Remember that pragma suppress does NOT, despite its name, promise
to suppress exceptions. It simply allows the compiler to assume that
the check in question will not be violated, i.e. that any program execution
containing a failure of the check is erroneous.

For a vendor to allow you to exceed the range of Year_Number in this manner
would to me be an extension of the language, and a highly undesirable one.

I will repeat my earlier position, the only thing that makes sense is to
have a separate package that provides an extended year range. if you really
want to get into the language extension business, you can have a switch
that substitutes this extended calendar for the regular one, but that
seems a poor choice to me, much better to just have a separate package
called Extended_Calendar, or somesuch.

(although I must say, I can't see this being at the top of any implementors
 priority list :-)

Re: Software Engineering News Brief

[Robert Dewar]

Stefan says

"Does any part of the GNAT toolset ever need to sort these files in
chronological order or perform any other form of timestamp comparison ?"

The answer is yes,
and it does it properly
see the code if you want more details
and of course the only reason for the comparison is to choose the
message to be given in an error situation.

Re: Software Engineering News Brief

[Norman H. Cohen]

Paul Eggert wrote (about the range of years 1901 to 2099):

> Actually, many kinds of applications require support for dates outside
> that range; it was shortsighted of the Ada standard-writers to prohibit
> implementations from having better standard date support than that.

But if some implementations have better "standard date support" than
others, it's no longer "standard", is it?  

The predefined Calendar package has a type for representing times and
dates in the range 1901 to 2099, but an implementation can provide a
nonstandard package that supports a different range, as long as the
implementation ALSO provides the standard package.  Similarly, a
programmer can easily write hiw own package supporting a different
range.

The intended use of the package Calendar, reflected in its design, is
the manipulation of dates and times during and near to the execution of
the program, most obviously to query the current time or to establish
the time at which some action should be performed.  (Ada programs that
use package Calendar construct dates prior to the advent of Ada are
quite rare.  The example of such a program on page 88 of Ada as a Second
Language is intended to be facetious, as is made clear by the text
introducing it.)  The predefined package Calendar was not designed for
calendrical calculations such as determining the day of the week on
which November 11 occurred in the year 1376, and does not provide
facilities that would be particularly helpful in making such
calculations.  If you were writing an application that required such
calculations, you would probably write your own, quite different,
package.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: Software Engineering News Brief

[Marin David Condic, 561.796.8997, M/S 731-93]

Paul Eggert <eggert@TWINSUN.COM> writes:
>This hilarious (and obviously false) claim reminds me of the confident
>announcement I found in Sun's bug database a few months ago to the effect that
>Solaris doesn't have any year-2000 problems because the kernel merely
>counts seconds since 1970.  Well, that's true as far as it goes, but it
>turns out that several Solaris applications (SCCS and xterm, for example)
>_do_ have year-2000 problems because the application developers saw fit
>to take the year modulo 100, or subtract 1900 from the year, or some
>such nonsense.  To Sun's credit when I pointed out some of these
>problems they quickly toned down their announcement, and they are
>testing the next Solaris release more carefully for year-2000 bugs.
>
    I am reminded of a statement made by some CEO of some nameless
    computer manufacturer. The claim was: "So far as I know, we've
    never had an undetected error in the operating system..."

    I wish I could recall who said this and when so I could add it to
    my quote list. (For some reason, Honeywell comes to mind - but I
    couldn't be sure it wasn't Burroughs or someone else... Ahh the
    memory leaks I seem to have with no garbage collection operating
    in my brain!)

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    "That which belongs to another."

        --  Diogenes, when asked what wine he liked to drink.
===============================================================================

Re: Software Engineering News Brief

[Robert Dewar]

Paul Eggert says

"... which is why the next version of Ada should support Gregorian dates
all the way back to at least the year 1, if not before.  Trying to
match the historical introduction of the Gregorian calendar
leads to severe politico-technical problems.  For an example of this
see my May 1995 comp.risks article about Sybase's historically naive
practice of arbitrarily rejecting Gregorian dates before 1753."

That sounds silly to me. This is a highly specialized requirement that
should be provided by auxiliary packages, not by the central package
for dealing with near by dates that is primarily intended for use in
control of time related processing (note that Calendar is still in the
tasking chapter, even in the new RM.

Also, Gregorian dates are quite tricky, because the change over in the
calendar happened at different times in different parts of the world, so
you need detailed geo-political localization for such processing. Again,
much more suitable for some auxialiry package than for Calendar, which 
does not even have time zone support.

As for prohibiting implementations from extending the range, yes, this is
quite deliberate, but you state it in a peculiar manner. There is nothing
to stop an implementation from providing an extended calendar package
with whatever range of dates is needed, and this can easily be written s
a portable package, but you certainly do NOT want different implementations
to implement the standard library with such gratuitous variations. Ada is
much more concerned with portability than you are I guess.

If there is really a need for such extended calendar support from real
Ada programmers writing real Ada programs, rather than just in the context
of CLA discussions, then such packages will appear, along with many other
useful packages, you cannot put support for all kinds of specialized
requirements into the language. I would say this is a perfect example of
specialized needs that should NOT be met in the standard language. I would
far rather have Ada implementors working to get their implementations more
efficient and more robust than wasting time in the library trying to figure
out when the switch to Gregorian dates happened in Lithuania.

In the GNAT world, people are very free in making suggestions about things
they would like to see in GNAT. No one ever mentioned this, so I find that
at least one measure of its extremely limited value.

Re: Software Engineering News Brief

[Fergus Henderson]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>Paul Eggert says
>
>"... which is why the next version of Ada should support Gregorian dates
>all the way back to at least the year 1, if not before.  Trying to
>match the historical introduction of the Gregorian calendar
>leads to severe politico-technical problems.  For an example of this
>see my May 1995 comp.risks article about Sybase's historically naive
>practice of arbitrarily rejecting Gregorian dates before 1753."
>
>That sounds silly to me. This is a highly specialized requirement that
>should be provided by auxiliary packages, not by the central package
>for dealing with near by dates that is primarily intended for use in
>control of time related processing (note that Calendar is still in the
>tasking chapter, even in the new RM.

I don't think it is a highly specialized requirement.  I think the
requirement for a generic date type the works over a large range of
dates is quite common.  Many programs let users enter dates, and
putting strict requirements on the dates entered is not unlike assuming
that no-one will ever want to enter a line with more than 80 characters.

>Also, Gregorian dates are quite tricky, because the change over in the
>calendar happened at different times in different parts of the world, so
>you need detailed geo-political localization for such processing.

Gregorian dates aren't tricky, the change-over from other systems is tricky.
That's why Paul Eggert suggested supporting Gregorian dates only, even
for dates before the Gregorian system was used.

>I would say this is a perfect example of
>specialized needs that should NOT be met in the standard language. I would
>far rather have Ada implementors working to get their implementations more
>efficient and more robust than wasting time in the library trying to figure
>out when the switch to Gregorian dates happened in Lithuania.

You misunderstood what Paul Eggert was saying.  His suggestion would *not*
require implementors to figure out when the switch to Gregorian dates
happened in Lithuania or anywhere else.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: Software Engineering News Brief

[Robert Dewar]

Fergus said

  "I don't think it is a highly specialized requirement.  I think the
  requirement for a generic date type the works over a large range of
  dates is quite common.  Many programs let users enter dates, and
  putting strict requirements on the dates entered is not unlike assuming
  that no-one will ever want to enter a line with more than 80 characters."

Almost all programs that let users enter dates will want to consider
a date from the 25th century as illegal, just as illegal as the 30th of
February. It is indeed a specialized requirement to need dates very far
from the present. I certainly have never written such a program, and I
have written MANY programs that handle dates!

  "Gregorian dates aren't tricky, the change-over from other systems is tricky.
  That's why Paul Eggert suggested supporting Gregorian dates only, even
  for dates before the Gregorian system was used."

Well I know that's what he said, but I thought it must be a slip, because
it is so obviously an undesirable suggestion. To accept dates before the
18th century without comment or error, and then misinterpret them seems
highly error prone. Any program that wants to deal with dates before the
switch over must surely worry for itself about how to deal with this
situation. If I have a program that tells me the day of the week for any
date, and I use it to see what day of the week the Magna Carta was signed,
I either want the right answer, or an error, I certainly do NOT want to
get an incorrect answer corresponding to what the day would have been
had the Pope switched over the dates much earlier!

Also, dates that go outside the Ada range are tricky for another reason, since
they need geopolitical normalization in any case. The question of whether a
year is a leap year or not is not a scientific or astronomical one, it is a
political one, since it depends on the laws of the country involved. All
countries agree for the Ada range of dates, but when you wander outside
this range, countries will disagree unless they change their laws. Again,
deciding whether you want the date according to the current law, or according
to some other scheme, is surely something a program must decide for itself.

Dates are not as simple as you think! In particular, I am pretty sure that
when people talk about Gregorian dates, they do not mean what they say (i.e.
they are not talking about dates according to the scheme that Pope Gregory
decreed). That again is because the system of leap years has changed since
then, so that in some countries the laws of the country do not correspond
to Gregorian dates.

For example, I know the rule that every 100 years is not a leap year, except
that every 400 years is a leap year, but I do not know if this corresponds to
the current legislation of the US. There are also higher order corrections
proposed, so if you want to do a program that converts from Star Dates to
standard dates, you will have to find out the details of Federation legislation
regarding dates first.

Re: Software Engineering News Brief

[Larry J. Elmore]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article
<dewar.848230046@merv>...
> Almost all programs that let users enter dates will want to consider
> a date from the 25th century as illegal, just as illegal as the 30th of
> February. It is indeed a specialized requirement to need dates very far
> from the present. I certainly have never written such a program, and I
> have written MANY programs that handle dates!

I agree that it's unnecessary for Ada to directly support dates rtanging
over thousands of years, but IMHO the 1900-2099 A.D. limit is just too
small. For example, any program dealing with birthdates of people (and I'm
thinking mainly in the health care field right now where many patients are
elderly), many people alive today were born before 1900. Ada *should*
directly support dates widely used in many programs today. Granted, this is
a self-correcting problem as those people born before 1900 die off (and,
granted, there's not many of them left now as it is), but I honestly can't
see why the Calendar package is so limited. Why would it have been so bad
to give it a somewhat larger range?


-- 
Larry J. Elmore

"A man's worth is no greater than the worth of his ambitions."
-- Marcus Aurelius Antoninus, "Meditations," c. 170 A.D.

"The universe is change; our lives what our thoughts make of it."
-- Ibid.

Re: Software Engineering News Brief

[Robert Dewar]

"I agree that it's unnecessary for Ada to directly support dates rtanging
over thousands of years, but IMHO the 1900-2099 A.D. limit is just too
small. For example, any program dealing with birthdates of people (and I'm
thinking mainly in the health care field right now where many patients are
elderly), many people alive today were born before 1900. Ada *should*
directly support dates widely used in many programs today. Granted, this is
a self-correcting problem as those people born before 1900 die off (and,
granted, there's not many of them left now as it is), but I honestly can't
see why the Calendar package is so limited. Why would it have been so bad
to give it a somewhat larger range?"

Going back a bit further would have been simple enough, true, assuming
everyone agrees that 1900 was not a leap year (is that true, across all
governments likely to be involved?)

On the other hand, I still think this is a very minor issue. Calendar
is basically designed for support of real time (as I noted before it
is in the tasking chapter). True it could have been generalized a bit,
but there was no sentiment to do so during the revision history, none of
the revision requests mentioned it, and no one ever raised this as a
significant issue. Whether it would have been worth the incompatibility
if someone had, who knows.

Meanwhile, an extended date package is a rather trivial thing to write, how
about someone who thinks it is important, and therefore must have already
done it (or are these all theoretical comments), submitting the code, and
we will pop it in the GNAT library!

Re: Software Engineering News Brief

[Larry Kilgallen]

In article <01bbd490$356f8220$686700cf@ljelmore.montana>, "Larry J. Elmore" <ljelmore@montana.campus.mci.net> writes:

> I agree that it's unnecessary for Ada to directly support dates rtanging
> over thousands of years, but IMHO the 1900-2099 A.D. limit is just too
> small. For example, any program dealing with birthdates of people (and I'm
> thinking mainly in the health care field right now where many patients are
> elderly), many people alive today were born before 1900.

And genealogists might want support a few centuries back, or a few
more centuries depending on how successful they have been in their
work.  As one goes further back, human assumptions about rule sets
diverge.

> elderly), many people alive today were born before 1900. Ada *should*
> directly support dates widely used in many programs today.

I would think a health-care date package, and a genealogical date
package would be a better approach.  The former might merely extend
the years, while the latter would handle localization issues. Look
at the more complete family of Machintosh toolbox date calls for
a set of capabilities way beyond what the average programmer should
be forced to face.  The Ada standard date package should provide for
those whose needs are _not_ specialized arould date issues.  The
same should be true in other areas.

Larry Kilgallen

Re: Software Engineering News Brief

[Matt Kennel]

Robert Dewar (dewar@merv.cs.nyu.edu) wrote:
: Paul Eggert says

: "... which is why the next version of Ada should support Gregorian dates
: all the way back to at least the year 1, if not before.  Trying to
: match the historical introduction of the Gregorian calendar
: leads to severe politico-technical problems.  For an example of this
: see my May 1995 comp.risks article about Sybase's historically naive
: practice of arbitrarily rejecting Gregorian dates before 1753."

: That sounds silly to me. This is a highly specialized requirement that
: should be provided by auxiliary packages, not by the central package
: for dealing with near by dates that is primarily intended for use in
: control of time related processing (note that Calendar is still in the
: tasking chapter, even in the new RM.

: Also, Gregorian dates are quite tricky, because the change over in the
: calendar happened at different times in different parts of the world, so
: you need detailed geo-political localization for such processing. Again,
: much more suitable for some auxialiry package than for Calendar, which
: does not even have time zone support.

Let's stop complaining about the problem and start thinking about its
fundamentals correctly.   

There are indeed universal and uniform notions of "date", for example,
counting absolute days, defined perhaps as count of maximum solar altitude
over some fixed longitude.

This is a *solved* problem for astrophysical ephemerides.  

(You also have to decide whether you care about the extra 'apparent' angular
rotation from the orbit of Earth around Sun in addition to the spin rotation;
for human notions of 'date', the answer is "yes"). 

Ok, we now have absolute days, counting in integers.  I believe this is called
"Julian date". 

Quoting from 'Numerical Recipes in C', pg. 12, 

 Astronomers number each 24-hour period, starting and ending at noon, with a
 unique integer, the Julian Day Number.  Julian Day Zero was a very long time
 ago; a convenient reference point is that Julian Day 2440000 began at
 noon of May 23, 1968. 
 
Julian dates can be added and subtracted like natural integers.

Given this representation, the translation to MM/DD/YY is a *transformation
layer* (model vs. view)
depending on location, time, religion, nationality, et cetera. 

E.g. RussianAndSovietOrthodoxDateTranslator, WesternEuropeanDateTranslator,
     FrenchRevolutionDateTranslator, RomanEmpireDateTranslator


I wonder if this also addresses the question of whether "math or science" are
useful for computer programmers. 


--
Matthew B. Kennel/mbk@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT
Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/ 

Re: Software Engineering News Brief

[Dave Sparks]

>>>>> "RD" == Robert Dewar <dewar@merv.cs.nyu.edu> writes:

  RD> ...

  RD> Also, dates that go outside the Ada range are tricky for another
  RD> reason, since they need geopolitical normalization in any case. The
  RD> question of whether a year is a leap year or not is not a scientific
  RD> or astronomical one, it is a political one, since it depends on the
  RD> laws of the country involved. All countries agree for the Ada range
  RD> of dates, but when you wander outside this range, countries will
  RD> disagree unless they change their laws. Again, deciding whether you
  RD> want the date according to the current law, or according to some
  RD> other scheme, is surely something a program must decide for itself.

According to <ftp://elsie.nci.nih.gov/pub/tzdata95i.tar.gz>

# Catholic Romania switched from the Julian to the Gregorian calendar on
# on 1919 Mar 18.  Greek Orthodox Romania switched on 1920 Mar 18.

(sic).  These dates seem to be within the ADA range.  The same
source gives other countries (including Russia) which did not
change until after 1900.

-- 
        Dave.Sparks@sisyphus.demon.co.uk        (Staffordshire, England)

Re: Software Engineering News Brief

[Norman H. Cohen]

Larry J. Elmore wrote:

> I agree that it's unnecessary for Ada to directly support dates rtanging
> over thousands of years, but IMHO the 1900-2099 A.D. limit is just too
> small. For example, any program dealing with birthdates of people (and I'm
> thinking mainly in the health care field right now where many patients are
> elderly), many people alive today were born before 1900.

You are confused about the "direct support" that Ada provides for
dates.  Like any general-purpose programming language, Ada allows a
programmer to construct any representation of dates appropriate for his
application, e.g. a string of the form yyyymmdd, along with a set of
subprograms to manipulate that representation.  

In addition, since Ada is (among other things) a real-time programming
language, the standard Ada library includes a package named Calendar
with one particular representation--a type named Time capable of
representing any time from the year 1901 to the year 2099 to an accuracy
of 20 milliseconds or better (with a recommendation that implementations
provide a representation accurate to 0.1 milliseconds if the underlying
system supports it).  The operations of type Time are:

   - decomposing a Time value into year, month, day, and seconds
   - composing a Time value from these components
   - comparing two Time values for <, <=, = >=, or >
   - subtracting two Time values within 24 hours of each other to
        obtain a difference in seconds (of type Duration)
   - adding or subtracting a number of seconds in the range
        -86,400 to 86,400 (86,400 seconds = 1 day) to a Time value
        to obtain a new Time value 

That's it.  There are no operations to add a specified number of days,
years, or months to a Time value to obtain a time value, no operations
dealing with days of the week, etc.  Sure there are applications that
require such capabilities, but the Calendar package was never meant for
those applications.  Unless your health-care application has a
requirement to pinpoint the birth of somebody born in 1899 to within 20
milliseconds, I can't imagine why you would consider the type
Calendar.Time as the appropriate representation for birthdates.

On the other hand, Calendar.Time might be appropriate for a time-machine
control program if only the range were wider... ;-)

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: Software Engineering News Brief

[Robert Rodgers]

kilgallen@eisner.decus.org (Larry Kilgallen) wrote:
>In article <01bbd490$356f8220$686700cf@ljelmore.montana>, "Larry J. Elmore" <ljelmore@montana.campus.mci.net> writes:
>> I agree that it's unnecessary for Ada to directly support dates rtanging
>> over thousands of years, but IMHO the 1900-2099 A.D. limit is just too
>> small. For example, any program dealing with birthdates of people (and I'm
>> thinking mainly in the health care field right now where many patients are
>> elderly), many people alive today were born before 1900.

I don't see why you wouldn't want to use, say, a 128bit dating system.
This would allow indexing the contents of the filesystem by date --
including the geological record, and all of human history.  For a huge
database system (say, of the sort that futurists like to talk about
for ~50 to ~100 years from now) this would be quite useful (especially
since timestamp on files has pretty much become useless).

The compiler could catch whacky dates at compile time -- and allow
their use if desired.  There is no reason whatsoever to limit the
language proper to a specific date period.


rsr

www.wam.umd.edu/~rsrodger                   b   a   l   a   n   c   e
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Reasonable is expecting excellence from those who expect it from you.

Re: Software Engineering News Brief

[Keith Thompson]

In <dewar.848250425@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Going back a bit further would have been simple enough, true, assuming
> everyone agrees that 1900 was not a leap year (is that true, across all
> governments likely to be involved?)

The answers to this and many other calendar questions can be found in
the Calendar FAQ at <http://www.pip.dknet.dk/~pip10160/calendar.html>.

Several countries switched from the Julian to the Gregorian calendar
after 1900, including Russia, Greece, China, and possibly Japan.
(1900 is a leap year under the old Julian calendar, but not under the
current Gregorian calendar.)  Whether those countries refer to dates
before the change using the current calendar or the one in effect at
the time is another question -- probably for another newsgroup.

In any case, those countries could have problems with package Calendar
even if it doesn't cover dates before 1901, since package Calendar
doesn't reflect the skipped dates.  To see an example of the problem,
here's the output of the Unix command "cal 9 1752".

   September 1752
 S  M Tu  W Th  F  S
       1  2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

See also the newsgroup comp.software.year-2000.

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
FIJAGDWOL

Re: Software Engineering News Brief

[Mark A Biggar]

In article <dewar.848230046@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>Fergus said
>  "Gregorian dates aren't tricky, the change-over from other systems is tricky.
>  That's why Paul Eggert suggested supporting Gregorian dates only, even
>  for dates before the Gregorian system was used."
>Well I know that's what he said, but I thought it must be a slip, because
>it is so obviously an undesirable suggestion. To accept dates before the
>18th century without comment or error, and then misinterpret them seems
>highly error prone. Any program that wants to deal with dates before the
>switch over must surely worry for itself about how to deal with this
>situation. If I have a program that tells me the day of the week for any
>date, and I use it to see what day of the week the Magna Carta was signed,
>I either want the right answer, or an error, I certainly do NOT want to
>get an incorrect answer corresponding to what the day would have been
>had the Pope switched over the dates much earlier!

Please note that even the current Ada Year Range of 1901..2099 has the
switch over problem as Russia didn't convert from Julian to Gregorian
until sometime in the 1920's.

--
Mark Biggar
mab@wdl.lmco.com

Re: Software Engineering News Brief

[Martin Tom Brown]

In article <56q5e3$ntv@gaia.ns.utk.edu> %%spam "Matt Kennel" writes:

> Robert Dewar (dewar@merv.cs.nyu.edu) wrote:

> : That sounds silly to me. This is a highly specialized requirement that
> : should be provided by auxiliary packages, not by the central package
> : for dealing with near by dates that is primarily intended for use in
> : control of time related processing (note that Calendar is still in the
> : tasking chapter, even in the new RM.
> 
> : Also, Gregorian dates are quite tricky, because the change over in the
> : calendar happened at different times in different parts of the world, so
> : you need detailed geo-political localization for such processing. Again,
> : much more suitable for some auxialiry package than for Calendar, which
> : does not even have time zone support.
> 
> Let's stop complaining about the problem and start thinking about its
> fundamentals correctly.   

Yes you are right. This thread seems to be a argument so far 
which confuses details of the input/output package for dates 
with the internal machine representation of the entity.

Remember that in some countries US style dates MM/DD/YYYY are not 
standard and so DD/MM/YYYY is used in the UK and YY'/MM/DD in Japan 
(YY' is YYYY-<year of succession of Emperor reigning in YYYY>)

> There are indeed universal and uniform notions of "date", for example,
> counting absolute days, defined perhaps as count of maximum solar altitude
> over some fixed longitude.

The history of the derivation of accurate time systems is too messy 
and off topic to deal with here. It is worth taking a look at the
Explanatory Suppliment to the Astronomical Ephemeris & Nautical Almanac.
There is a very throrough discussion of how the various civil and
astronomical Ephemeris time systems and SI definitions are linked.

The same is true for details of geographic adoption of calendars
(problems also exist in this area of knowing *where* historic
borders actually were located in some hotly disputed areas).

> This is a *solved* problem for astrophysical ephemerides.  

Indeed and the solution has existed for a very long time.

> Ok, we now have absolute days, counting in integers. 
> I believe this is called "Julian date". 

Yes - the "Julian Day Number" is defined on the integers,
and its extension "Julian Date" is defined on the reals to 
include fractions of a day to specify time of observation.

Note it was defined so that from Greenwich the JD would change at 
midday so astronomical observations on a single night get the same JD.
 
> Julian dates can be added and subtracted like natural integers.
> 
> Given this representation, the translation to MM/DD/YY is a 
> *transformation layer* (model vs. view) depending on location, 
> time, religion, nationality, et cetera. 
> 
> E.g. RussianAndSovietOrthodoxDateTranslator, WesternEuropeanDateTranslator,
>      FrenchRevolutionDateTranslator, RomanEmpireDateTranslator

I heartily agree, but then being a scientist and former astronomer
based in the UK I could be accused of Greenwich-o-centric bias here.

> I wonder if this also addresses the question of whether 
> "math or science" are useful for computer programmers. 

I think it is actually a beautiful example of the relevance 
of existing knowledge outside computing to software problems.

It is worth also noting here that in addition to the Y2K problem
in 1988 *and* 1992 leap year related faults occurred in various 
banking systems which caused chaos both on 29/2 and 31/12. 
It appears this leap year may be OK - so far so good anyway.

Regards,
-- 
Martin Brown  <martin@nezumi.demon.co.uk>     __                CIS: 71651,470
Scientific Software Consultancy             /^,,)__/

Re: Software Engineering News Brief

[Keith Thompson]

In <56q5e3$ntv@gaia.ns.utk.edu> mbk@caffeine.engr.utk.edu (Matt Kennel) writes:
[...]
> Let's stop complaining about the problem and start thinking about its
> fundamentals correctly.   
> 
> There are indeed universal and uniform notions of "date", for example,
> counting absolute days, defined perhaps as count of maximum solar altitude
> over some fixed longitude.
[...]
> Given this representation, the translation to MM/DD/YY is a *transformation
> layer* (model vs. view)
> depending on location, time, religion, nationality, et cetera. 
> 
> E.g. RussianAndSovietOrthodoxDateTranslator, WesternEuropeanDateTranslator,
>      FrenchRevolutionDateTranslator, RomanEmpireDateTranslator

An Ada implementor could provide this kind of thing within the language.
The type Ada.Calendar.Time is private.  The full type could easily be
declared to represent times over a much longer range than 1901..2099.
It could even be a Julian Day Number (if it has sufficient precision).

The Year, Month, Day, and Seconds functions, and the Split procedure,
in package Calendar are required to raise Time_Error if their
argument represents a date outside the range 1901..2099, but an
implementation could provide child packages of Calendar implementing other
"transformation layers".

For example:

package Ada.Calendar.Extended is
   subtype Year_Number is Integer range 1 .. 9999;
 
   procedure Split (Date    : in     Time;
                    Year    :    out Year_Number;
                    Month   :    out Month_Number;
                    Day     :    out Day_Number;
                    Seconds :    out Day_Duration);

   --  We would also declare functions Year, Month, Day, Seconds,
   --  Time_Of, "+", "-", "<", "<=", ">", and ">=".

end Ada.Calendar.Extended;

Whether it really makes sense to extend the representation of type
Time for this purpose is another question.  The advantage of this
approach is that it uses a single type, Ada.Calendar.Time, for multiple
transformation layers.  The disadvantage is that it can make existing
operations on type Time less efficient, particularly the "delay until"
statement that's built into the language.

Note that a user, as opposed to an implementer, cannot extend the range
of type Time, though of course you can declare whatever types you want
in a user-defined package.

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
FIJAGDWOL

Re: Software Engineering News Brief

[Frank Manning]

In article <3290A899.2052@watson.ibm.com> Norman H. Cohen
<ncohen@watson.ibm.com> writes:

> On the other hand, Calendar.Time might be appropriate for a time-machine
> control program if only the range were wider... ;-)

Agreed. I'd think the minimum range should be 1885..2015.

I do think Ada is a good choice, though. After all, if you're gonna
build a time machine, you might as well do it with a little style.

-- Frank Manning

Re: Software Engineering News Brief

[Robert I. Eachus]

In article <3290e3b8.3406981@news.wam.umd.edu> rsrodger@wam.umd.edu (Robert Rodgers) writes:

  > I don't see why you wouldn't want to use, say, a 128bit dating system.
  > This would allow indexing the contents of the filesystem by date --
  > including the geological record, and all of human history.  For a huge
  > database system (say, of the sort that futurists like to talk about
  > for ~50 to ~100 years from now) this would be quite useful (especially
  > since timestamp on files has pretty much become useless).

    The problem is that there are incommensurate dating schemes.  I
may know that a particular event occured in the second year of Ramses
the Second's reign and at the same time be debating furiously which
century of the Hebrew calendar that date corresponds to.  If you need
a wide date range, you need more than one supported date format, and
(in Ada) a discriminant as part of each date.  Today is November 20,
1996 Gregorian, and November 7, 1996 Julian.  Live with it.


--

					Robert I. Eachus

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

Re: Software Engineering News Brief

[Robert Dewar]

Paul Eggert says

"> To accept dates before the 18th century without comment or error,
> and then misinterpret them seems highly error prone.

On the contrary, I've helped write some applications where quietly
accepting pre-18th-century dates was precisely the right thing to do.
A calendar package should not presume to tell applications what the
proper range is -- it should support the calendar,
and let applications worry about data validity checking."



An exactly wrong argument, at least for the Ada design philosophy. You
are saying "let me do this, beause I have at least some applications
where it is what I want -- yes, I know that other applicatoins may be
surprised at the behavior, but so what -- programmers should be careful."

As I have said many times, I have no objection to a specialized calendar
package that provides so-called Gregorian dates back to 4004 BC if that
is what you want, and indeed why not spend your effort writing such a
package!

But to suggest that the standard built-in package have this kind of shaky
semantics, i.e. semantics that so obviously conflicts with one reasonable
expectation (i.e. if the Pilgrims landed on a certain date, that date
should correspond to what the package deals with) is a truly bad idea!

Re: Software Engineering News Brief

[Paul Eggert]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> To accept dates before the 18th century without comment or error,
> and then misinterpret them seems highly error prone.

On the contrary, I've helped write some applications where quietly
accepting pre-18th-century dates was precisely the right thing to do.
A calendar package should not presume to tell applications what the
proper range is -- it should support the calendar,
and let applications worry about data validity checking.

> All countries agree for the Ada range of dates

That is not true for the early part of this century, when many
countries still used the Julian calendar for most purposes; it's not
even entirely true now, as some countries still use non-Gregorian
calendars for some legal purposes.  (And whether it will be true through
the year 2099 is more than either you or I can say.  :-)

But all this is irrelevant for the Ada calendar package, which
(understandably) supports only the Gregorian calendar.

> I am pretty sure that when people talk about Gregorian dates, they do not
> mean what they say (i.e. they are not talking about dates according to the
> scheme that Pope Gregory decreed)....

There isn't any real disagreement about what `Gregorian' means these days
(except perhaps before the year 1).  If there were real disagreement,
then even the limited-range Ada calendar package would be questionable.

Re: Software Engineering News Brief

[Paul Eggert]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> But to suggest that the standard built-in package have this kind of shaky
> semantics, i.e. semantics that so obviously conflicts with one reasonable
> expectation

If the Ada standard couldn't specify semantics that obviously conflict
with ``one reasonable expectation,'' then there wouldn't be a standard.
The whole point of a standard is to specify one among several reasonable
solutions to a problem.  All I'm saying is that for calendars, the most
reasonable solution is the Gregorian calendar.

I agree that dates are not as simple as you think.  But I'm afraid that
a good deal of the calendrical misinformation in this thread has been posted
by you: ``all countries agree for the Ada range of dates'' (they don't),
``the system of leap years has changed since [Pope Gregory's scheme]''
(it hasn't).

Perhaps the Ada standardization committee chose the years 1901-2099 based
on similar misunderstandings.  That wouldn't be too surprising,
as few computer language experts are also experts about timekeeping.
It reminds me of the C standard's bug in leap second handling:
the C standard allows for two leap seconds in the same minute
(an impossibility), because the C committee misunderstood leap seconds.

In any case, I urge the Ada standard committee to contact a genuine calendar
implementation expert before making any future decisions in this area.
A good choice would be Professor Ed Reingold of the University of Illinois,
coauthor of ``Calendrical Calculations'', Software--Practice & Experience
20, 9 (1990), 899-928.