From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: **
X-Spam-Status: No, score=2.6 required=5.0 tests=BAYES_20,INVALID_DATE,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!gem.mps.ohio-state.edu!ginosko!uunet!murtoa.cs.mu.oz.au!munnari.oz.au!comp.vuw.ac.nz!news
From: lindsay@comp.vuw.ac.nz (Lindsay Groves)
Newsgroups: comp.lang.ada
Subject: Re: of a year, years, and half a year (was Re: (none))
Message-ID: <1989Sep7.043801.16887@comp.vuw.ac.nz>
Date: 7 Sep 89 04:38:01 GMT
References: <8909022213.AA06286@ajpo.sei.cmu.edu> <2007@munnari.oz.au> <13711@grebyn.com>
Reply-To: lindsay@taputeranga.comp.vuw.ac.nz (Lindsay Groves)
Organization: Dept of Comp Sci, Victoria University of Wellington, NZ.
List-Id: <comp.lang.ada>

Newsgroups: comp.lang.ada
Subject: Re: of a year, years, and half a year (was Re: (none))
Summary: 
Expires: 
References: <8909022213.AA06286@ajpo.sei.cmu.edu> <2007@munnari.oz.au> <13711@grebyn.com>
Sender: 
Reply-To: lindsay@taputeranga.comp.vuw.ac.nz (Lindsay Groves)
Followup-To: 
Distribution: 
Organization: Dept of Comp Sci, Victoria University of Wellington, NZ.
Keywords: 

In article <13711@grebyn.com> karl@grebyn.com (Karl Nyberg) writes:
> ...
> ...                                 I'm surprised that C.hackers (of all
>people) wouldn't start with 0-based counting (like their poor arrays, K&R,
>1.6, p 20), making the current millenium from 1000 .. 1999, and the current
>decade of the 1980s from 1980 .. 1989.  Then the year 1990 would indeed MARK
>the end of the current decade (known as the eighties, as all the years are
>of the form 198[0-9]) and begin the first year of the nineties.
>
>I can't fathom what DECADE we would call the years 1981 - 1990 (inclusive),
>but there's probably some name for it...

Why not call it the 199th decade?  This terminology is clearly superior, 
since it doesn't suffer from the ambiguity inherent in "the eighties",
"the nineties" etc -- viz. that they don't specify the century to which 
they belong, you have to somehow infer what century the speaker/write is
referring to, which may or may not be the century in which they made the
statement.

>Of course, all this wonderful analysis gets blown away by the fact that the
>year 1 BC is followed immediately by the year 1 AD (BCE, or whatever your
>religious conviction allows you to say).  Suffer the discontinuities of this
>concept of time (running from negative infinity to -1, followed by 1 to plus
>infinity, again depending upon your religions conviction), make the first
>decade of the current era have only 9 years, change the common meaning of
>things like "the eighties", the "nineteenth century", there are dozens of
>options.  And throw in the missing months during the calendar change, leap
>years, leap seconds, add various timezones for the folks in Australia, ...
>
>But I digress.  Maybe somebody can make this another Ada 9X language issue.
>I just love having more language issues for 9X.  It'll give me something to
>do this winter and spring!  :-)

It seems to me that the issue for Ada 9X (or any other language whose
designers care to address such issues) is how you then define YEAR as
a data type, which should clearly be available in a standard predefined
package.  First, we need an unbounded integer type.  Then we need to define
YEAR as a subtype of this type, which does not include 0.  This could be
done either by taking the union of two semibounded integer types
(range -INFINITY .. -1 and range 1 .. INFINITY) or by some form of type
subtraction (e.g. (range -INFINITY .. INFINITY) - 0).  Since Ada does not 
currently have either type union or type subtraction, it will be necessary
to consider these features carefully to determine how general they need to
be, devise formal semantics, consider implementation problems etc, so the
alternatives can be evaluated and a final proposal decided upon.

One issue that needs to be addressed is how to define operators on such types.
Should SUCC(-1) give 1, or should this raise an exception?  Perhaps any
program evaluating this expression should cause a picture of a bright star to
be displayed on the user's terminal!

I think I'll leave the rest of the issues of be debated by the appropriate
bodies and get back to some work.

	Lindsay