Mark J. Reed wrote on Thu, 20 Oct 2005 16:45:23 -0400:
>On 10/20/05, Nigel Garvey <email@hidden> wrote:
What astronomers tend to use is for their own convenience; it's not the
Gregorian calendar per se. It's convenient for them to equate years to
cardinal numbers so that they can do mathematical calculations with them.
The numbers in a calendar are ordinals (first Year of our Lord, first day
of March, first month of the year) which identify particular periods with
respect to the era in which they occur. (In this case, the "Christian
Era".) The "0th Year of our Lord" is as meaningless as the "0th of September"
and later
"0 AD" is not part of the calendar and is linguistic nonsense.
As both a calendarist and a linguist (amateur on both counts, but with
a lot of history in the hobbies), I must disagree. It is true
that "0th" as an ordinal is arguably meaningless from a logic
standpoint, although that doesn't keep it from being used, usually to
represent the insertion of something before what is commonly considered
the first item (the "zeroth step" in a recipe is to get the
ingredients; the Zeroth Law of Robotics; etc.). But historically
the year number used with both the Latin Anno Domini and the English
"In the Year of our Lord" is a cardinal, not an ordinal, and there is
absolutely nothing nonsensical about "in the year of our Lord
zero". Perhaps more relevantly, what you get back when you ask
AppleScript for the year property of a date object is not an ordinal,
it's a cardinal. :)
Anyway, sorry; I didn't mean to start an argument. This is basically what I was trying to get across:
It's all a question of convention, so despite the fact that you can get
an argument on the subject from almost anybody, there is no One True
Right Answer. This is my overarching point; you could call it my
zeroth one. :)
1. Computers represent dates in order to compute with them.
2. AD and BC years are not mutually compatible for computations
3. There is a logical extension of each era into the years normally delegated to the other
4. Using this extension doesn't break or violate anything except the
naïve assumptions of people who think that -44 should mean 44 BC, who
are going to have trouble anyway.
5. The current behavior of AppleScript with regard to years prior to 1 AD is broken.
Some minor points follow:
Many people have been
misled too into explaining the lack of a year 0 as due to the fact that
the number 0 wasn't invented until a few hundred years after the
Christian calendar was. But they've been thinking numbers rather than
calendars.
Ah, but there *is* a relationship there. If zero as a number -
and more importantly, the concept of negative numbers - had been known
(in Europe) at the time that Little Dennis established AD counting in
the 500s, there would have been no need for the Venerable Bede to come
up with the BC system later on. There would have already
been a natural way to refer to years before 1 AD: the year before
1 would be 0, the year before that -1, etc. The reason this
wasn't done isn't due to cardinality vs ordinality, but due to the fact
that there were no (non-fractional) numbers of any kind below 1 in the
European mind (and even the fractions were suspect, about on par with
imaginary numbers today :)).
Even mathematically, zero represents either nothing or a start point from
which something is measured. If it's used to measure time it should
ideally be at the junction of two years, not applied to an entire one.
That's inconsistent. If zero is the junction between two years,
then 1 should be the junction one year later, and so on. In which
case what you're really doing is rounding each point in time to one of
the nearby integers in order to determine what year that point
gets assigned to, and furthermore you're advocating
round-away-from-zero, which gives 0 a special status that is
undeserved. It's just a point on the line like any other, and
just like any other it should have a full 1-unit range of values that
round to it. It makes all sorts of math work without special
cases based on the signs of arguments, for one thing.
I agree with much of the rest of your post. I think the fact that
AppleScript date mathematics gets BC year numbers right must be an
incidental by-product of the process, since we're not supposed to see them.
I don't see how - something must be converting those year numbers,
otherwise they'd come out as 0 and negative. Which would be
mathematically preferable, but BC would be fine, too, if there were a
way to determine, given an arbitrary date object, whether its year were
AD or BC (without checking the weekday against some other reference).
Mark J. Reed <