PDA

View Full Version : cal for year 1700 is in error



lsatenstein
27th October 2017, 06:55 PM
cal 1700 says that the year has 366 days, but that is wrong.

Prior to 1580, the leap year rule was "every multiple of 4 years"

Following 1580, the rule was
Multiples of 100 are NOT leap years unless the year was a multiple of 400.

ergo,
1600 is a leap year
1700 is not a leap year
1800 is not a leap year
1900 is not a leap year
2000 is a leap year

To whom do I contact for a bug report? Fedora? Gnu?

glennzo
27th October 2017, 10:17 PM
Not to be a wise guy Leslie, but what does it matter? I don't see how it is relevant to 2017?

dswaner
27th October 2017, 10:29 PM
I'm sure that's not the only error, if you go that far back. But no doubt some history buff has a routine which adjusts for all the known calendar tweaks. Don't want to forget the leap seconds either.

ocratato
27th October 2017, 11:34 PM
You will probably get a "won't fix" response.

Great Britain and colonies did not adopt the Gregorian calendar until 1752, so it would be correct for 1700 to have had 366 days.

topiwala
27th October 2017, 11:47 PM
interesting. The "cal" as far as i know is a command of util-linux. Also terminal emulator on my android shows 29 days for 1700 and 1800 and even 2100 !

I think this is important.

The man page says under heading bugs

The cal program uses the 3rd of September 1752 as the date of the Grego‐
rian calendar reformation -- that is when it happened in Great Britain and
its colonies (including what is now the USA). Starting at that date,
eleven days were eliminated by this reformation, so the calendar for that
month is rather unusual. The actual historical dates at which the calen‐
dar reform happened in all the different countries (locales) are ignored.

Alternative calendars, such as the Umm al-Qura, the Solar Hijri, the
Ge'ez, or the lunisolar Hindu, are not supported.

RupertPupkin
27th October 2017, 11:49 PM
cal 1700 says that the year has 366 days, but that is wrong.

Prior to 1580, the leap year rule was "every multiple of 4 years"

Following 1580, the rule was
Multiples of 100 are NOT leap years unless the year was a multiple of 400.

ergo,
1600 is a leap year
1700 is not a leap year
1800 is not a leap year
1900 is not a leap year
2000 is a leap year

To[sic] whom do I contact for a bug report? Fedora? Gnu?
You don't have to contact anyone. Did you read the man page, specifically the BUGS section?:

BUGS
The cal program uses the 3rd of September 1752 as the date of the Gre-
gorian calendar reformation -- that is when it happened in Great
Britain and its colonies (including what is now the USA). Starting at
that date, eleven days were eliminated by this reformation, so the cal-
endar for that month is rather unusual. The actual historical dates at
which the calendar reform happened in all the different countries
(locales) are ignored.
So if you dislike the output of "cal 1700" then you're really going to hate to see what cal shows for September 1752:

$ cal 9 1752
September 1752
Su Mo Tu We Th Fr Sa
1 2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Notice the 11 days missing (Sep 3-13)? It looks like for dates prior to September 3 1752, cal uses the Julian calendar. And in the Julian calendar, 1700 is indeed a leap year:
https://en.wikipedia.org/wiki/Leap_year_starting_on_Monday#Julian_Calendar

By the way, cal is not a GNU program - it's part of the util-linux package, which is maintained by the Linux Kernel Organization. So you wouldn't contact the GNU people about cal anyway.

But gcal, on the other hand, is a GNU program: https://www.gnu.org/software/gcal/
And gcal also uses Sep 3 1752 as the default "changeover" date from Julian to Gregorian (reformed). One nice thing about gcal (which has loads more options than cal), is that you have the option to change that changeover date. From the gcal info pages:

'--gregorian-reform=1582|1700|1752|1753|ARGUMENT'
Set the period which was skipped during the Gregorian Reformation.
By default, Gcal runs in the "hybrid" calendar mode, i.e. Gcal
automatically changes from the Julian calendar system to the
Gregorian calendar system if output is related to dates after the
Gregorian Reformation has happened.
Upshot: use gcal, not cal. :)

topiwala
27th October 2017, 11:51 PM
You don't have to contact anyone. Did you read the man page, specifically the BUGS section?


Should the behavior be same in android?:confused:

RupertPupkin
27th October 2017, 11:58 PM
Should the behavior be same in android?:confused:
Yep, since it's probably using the Julian calendar for that year as well.

topiwala
28th October 2017, 12:15 AM
cal 2100 on my android terminal emulator shows 29 days.

lsatenstein
28th October 2017, 05:35 PM
Not to be a wise guy Leslie, but what does it matter? I don't see how it is relevant to 2017?

Glenn,
I wrote a date routine library, Julian, Gregorian, Unix, along with different calendaring algorithms. I did it for some cryptographic functions which use certain dates as an encryption salt value.

The fact that my thought processes are on calendaring means it forces me to reaction-flinch everytime I find
a year,month,day,dayofweek, leapyear miscalculation. :dis: I can't fall asleep at night, since it means
that I have to review my code, their code, and a third party's code to see if there is an error.:Y
And when my code proves right..:):):)

Is cal part of Linux raw, or a gnu library?

nonamedotc
29th October 2017, 02:04 AM
Is cal part of Linux raw, or a gnu library?

RupertPupkin has answered this above.

lsatenstein
29th October 2017, 07:10 AM
Bug was recorded against coreutils.

ocratato
29th October 2017, 08:32 AM
Bug was recorded against coreutils.

What are you suggesting they change ?

If you are suggesting the changeover date be 1582 this would make the program incorrect for a lot (most) places.

If I had to fix this I would add an option for the country code so the change over date from the Julian calendar could be taken into account. But I am not sure how a country code would work for countries that existed hundreds of years ago.

flyingdutchman
29th October 2017, 08:33 AM
You should send your bug report to Caesar Augustus. He was the first guy that buggered up Julius' calendar, which then took many centuries to get fixed again.

Anyhoo, that date is way before 1 Jan 1970, so your mileage will vary!

lsatenstein
29th October 2017, 08:03 PM
Basically, because the 1700 was declared a leapyear by cal, the days of the week for a date in 1700 and 1800 are in error, offset by more or less one day.

Look for julian to gregorian date demo websites and check out the day of the week. My code and their code and all the code I collected indicates cal is wrong.

And yes, september 3, is early, as a 10 day adjustment. Gregory did it for October. That means that with either 1582 correction, the last day of the year is corresponds.

ocratato
29th October 2017, 11:35 PM
OK, lets consider the case of an historical document written on Christmas day in 1750 in London, England.
The date on that document would be (according to cal): Tuesday, 25 Dec 1750.

Are you suggesting that such a real letter would have something different, because I cannot see how that would be the case. ?

dswaner
30th October 2017, 01:57 AM
As per the explanation at http://aa.usno.navy.mil/data/docs/JulianDate.php, since England and colonies did not adopt the Gregorian calendar until
September 1752, in 1700 they were still under the Julian calendar (leap year every 4th year), which means 1700 would have been a leap year, so cal is correct (unless you live in Italy ...).

lsatenstein
31st October 2017, 04:26 AM
From my code and from what was written up as an ISO standard, perhaps it's time for cal to be reviewed. I am attaching three documents
8601v2000.pdf ISO Standard
JulianDateExplanation.odt (libreoffice doc from Dr Dobbs Journal, by Peter Meyers. A very interesting read)
with code that matches Stanford Univ, and other sites.

weekiso.doc for some code that may be of interest to you

The importance of date routines is mainly for calculations for dates and finance
daysapart day1 to day2
workingDays between day1 to day2
Day of the week for a date
Manufacturing Calendars for production planning. (Many manufacturing calendars use a modulo 1000 day planning cycle).

ocratato
31st October 2017, 06:05 AM
Your examples for the use involves the future or the recent past - several hundred years ago seems a bit out of range.

The only practical purpose I can see for a calendar program going back into history is to determine what day of the week certain events happened on. In such a case the location is also an important factor since countries changed calendars at different times.

I've had a quick look at the documents you attached. I cannot see anything which convinces me that cal needs to be modified. Perhaps an option to specify the change over date, but otherwise it seems an entirely reasonable solution for what it does.

Please do not insist that it is wrong - it is correct for Britain and its colonies.

Jean Pierre
31st October 2017, 08:18 AM
England and colonies did not adopt the Gregorian calendar until
September 1752, in 1700 they were still under the Julian calendar (leap year every 4th year), which means 1700 would have been a leap year, so cal is correct (unless you live in Italy ...).
and unless you live in Montreal, which was not an English colony in 1700...

lsatenstein
31st October 2017, 06:03 PM
Interesting converter from calendar day to Julian. Try 1700 2 29

lsatenstein
13th November 2017, 12:58 AM
Well, my bug with Cal has been verified as follows:

date --date="1700-01-01 + 59 days" output:
Mon Mar 1 00:00:00 LMT 1700

date --date="1700-01-01 + 58 days" output:
Sun Feb 28 00:00:00 LMT 1700

So date and cal are inconsistent.
("date" from coreutils-8.27-6.fc26.x86_64)

dswaner
13th November 2017, 01:27 AM
The Modified Julian Date, which is the number of days since 1 Jan 4713 B.C., is used by astronomers, and sometimes historians. If "cal" and/or "date" are being considered for enhancement / correction, the "--MJD" option might be considered too. Ref: https://bowie.gsfc.nasa.gov/time/

ocratato
13th November 2017, 01:44 AM
Of course they are inconsistent.
date, based on the content of its man page, uses ISO 8601as its reference, and ISO 8601 uses the Gregorian calendar starting in 1582.
cal uses the Gregorian calendar, but starting in 1752, when it was adopted by Britain and its colonies (which includes the USA).

Both are correct relative to their specifications.

Anyone trying to do actual historical work should be aware that the calendars were adopted at several different times in different places and make the appropriate allowances. For example, there was a time when someone could get a letter in London that was written in Paris with a date on it that was in the future according to the English calendar.

Trying to use software outside of its specified limits is always going to problematic. Its up to us as users to understand those limits and make the appropriate adjustments.

If I were to make any change to the software (cal, date, etc.) it would be to add an option that allowed the user to specify when the Gregorian calendar was adopted.

dswaner
29th November 2017, 04:21 PM
The Fedora "jday" package does "astronomical Julian dates" or "Modified Julian Dates", which is the number of days (and fraction) starting from -4712-01-01 12:00:00. Current jday is 2458087.138194.

lsatenstein
29th November 2017, 04:42 PM
Hi dswaner

Cal 1700 and jdate are not in sync.
jdate (1700 1 1) +58 shows Feb 28
jdate (1700 1 1 )+59 shows Mar 1.

dswaner
29th November 2017, 05:43 PM
To hopefully clarify things a bit for the casual reader:
The "jcal" and "jdate" commands, from the "jcal" package do Jalali calendar dates.
The "jday" and "J2d" commands, from the "jday" package do "astronomical Julian" dates.