Let me clear up one thing first:
I am not proposing that IBM change its terminology. I am contending
that it is just as productive for the IT community to understand the
true origin of Julian dates as it is for the IT community to
understand the true origin of CSV. Which is to say, not particularly
productive. If you look at when I first brought the date issue up, it
was to say "well, if you want to be pedantic about CSV, let's be
pedantic about Julian dates".
Whatever silly choices Microsoft made when it implemented CSV export
from Excel, at least the files still have _C_ommas which serve to
_S_eparate the _V_alues. There is no vestige of Julian or Julius
remaining in IBM's Julian dates. Hell, there's not even a July,
because they have no months!
So please, let us just accept that CSV has come to mean what it has
come to mean, which is a variety of slightly incompatible things that
happens to include Excel's way of writing them. Let us also accept
that *JUL is what it is on the i, and move on. If we want to be aware
of and even espouse a more academic view, let us do it when we're
geeking out with our geek friends.
* * * * *
Geekery follows, which should be ignored by people doing actual work:
Second, I'm not completely sure what you mean by
skipped/missing days.
Are you referring to the point at which England
switched from the Julian calendar to the Gregorian,
and thus had to enact a one-time correction?
No. As a reflection of original creation\adoption by
the pope, not a reflection of any particular later
adoptions.
I picked England because most people in this country who have any
awareness at all about the switch from Julian to Gregorian may know
things like the difference between George Washington's Julian birthday
and his Gregorian birthday. But the correction I was referring to is
the same thing as (or a direct consequence of) the thing you are
referring to.
I alluded to the missing days to emphasize that even
what is claimed to represent the Gregorian calendar, is
possibly inaccurate. If one were consistent, then a
desire for complete accuracy in the use of the
term Julian should probably apply equally to the use of
the term Gregorian.
Well, there is "historical accuracy" which is *what actually
happened*, and "computational consistency" which is a coherent way to
do calculations. These two things are often not compatible, because
the real world is a messy place. In many cases, it's not even
possible to have perfect historical accuracy, because records are
conflicting, missing, damaged, etc. But we *can* have computational
consistency if we so choose, so why not choose it?
When we propagate a calendar system backward and forward indefinitely,
we say we are using a *proleptic* calendar. Thus, most of today's
date calculations use the "proleptic Gregorian calendar". In the
context of computations, it's usually clear that we want clean math,
not historical accuracy, so the "proleptic" is not explicitly stated.
I will say this: I have seen a lot of home-grown date code that
calculates as if the Julian calendar were in effect! (Specifically,
any code that assumes *every* 4th year is a leap year is effectively
using the Julian calendar, and not the Gregorian calendar.)
Sad; though such a calculation can be valid across four hundred
years.? But there is a lot of bad code, hardly limited to date
processing ;-)
Not even 400 years. Try just under 100 years in most cases; just
under 200 years in lucky cases. We're currently in a "lucky period"
where we have nearly 200 years of uninterrupted 4-year leap cycles.
1900 was not a leap year in places that adopted the Gregorian calendar
by then, and 2100 will not be a leap year either.
John Y.
midrange.com
