Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1518861 - Cal and Date do not correspond for dates before 14 September 1752
Summary: Cal and Date do not correspond for dates before 14 September 1752
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: util-linux
Version: 27
Hardware: All
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-29 16:26 UTC by Leslie Satenstein
Modified: 2018-07-18 15:37 UTC (History)
12 users (show)

Fixed In Version: util-linux-2.32
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-07-18 13:25:44 UTC


Attachments (Terms of Use)

Description Leslie Satenstein 2017-11-29 16:26:41 UTC
Description of problem:

Cal program and date program do not correspond for dates before 1752/10/1


cal 1700 shows 1 Jan as  Monday date -d "1700/1/1"  says it's Friday
date -d "1700/2/28" says Sunday 28 Feb  cal says Wednesday
date -d "1700/2/29" says invalid date   cal reports Thursday
date -d "1700/3/1   says Monday  Mar 1 cal says Friday

cal and date correspond for days beginning 1752/9/14 (Thursday)
The Gregorian calendar / julian calculations have the 10 day adjustment based on 1582, not 1752

Compare September for  year 1700. (cal 1700 vs cal 9 1700)  Again, it is in disagreement with itself.

cal 9 1700  shows the month of September. without the missing days.




Version-Release number of selected component (if applicable):

Since the Epoch

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

The cal program and calendar should be based on the "date" program algorithms.
The world knows the date conversion took place in 1582, not 1752.

Comment 1 Kamil Dudka 2017-11-30 09:53:54 UTC
Leslie, please remember to report 'cal' bugs against util-linux, not coreutils.  You also did not tell us which version of util-linux you tested it with but I doubt it has the fix for bug #1507271 included.

Comment 2 Karel Zak 2017-11-30 11:02:20 UTC
Leslie, is it another issue than bug #1507271 you already reported?

Comment 3 Leslie Satenstein 2017-12-13 02:47:08 UTC
YES

Comment 4 Karel Zak 2017-12-14 13:24:11 UTC
It seems the source of the problem is still the same. 

date(1) has no clue about 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

$ for x in $(seq 1 30); do date -d "$x-Sep-1752"; done
Fri Sep  1 00:00:00 LMT 1752
Sat Sep  2 00:00:00 LMT 1752
Sun Sep  3 00:00:00 LMT 1752
Mon Sep  4 00:00:00 LMT 1752   <---
Tue Sep  5 00:00:00 LMT 1752
Wed Sep  6 00:00:00 LMT 1752
Thu Sep  7 00:00:00 LMT 1752
Fri Sep  8 00:00:00 LMT 1752
Sat Sep  9 00:00:00 LMT 1752
Sun Sep 10 00:00:00 LMT 1752
Mon Sep 11 00:00:00 LMT 1752
Tue Sep 12 00:00:00 LMT 1752
Wed Sep 13 00:00:00 LMT 1752
Thu Sep 14 00:00:00 LMT 1752   <---
Fri Sep 15 00:00:00 LMT 1752
Sat Sep 16 00:00:00 LMT 1752
Sun Sep 17 00:00:00 LMT 1752
Mon Sep 18 00:00:00 LMT 1752
Tue Sep 19 00:00:00 LMT 1752
Wed Sep 20 00:00:00 LMT 1752
Thu Sep 21 00:00:00 LMT 1752
Fri Sep 22 00:00:00 LMT 1752
Sat Sep 23 00:00:00 LMT 1752
Sun Sep 24 00:00:00 LMT 1752
Mon Sep 25 00:00:00 LMT 1752
Tue Sep 26 00:00:00 LMT 1752
Wed Sep 27 00:00:00 LMT 1752
Thu Sep 28 00:00:00 LMT 1752
Fri Sep 29 00:00:00 LMT 1752
Sat Sep 30 00:00:00 LMT 1752

https://en.wikipedia.org/wiki/Calendar_(New_Style)_Act_1750

Wednesday 2 September 1752 was followed by Thursday 14 September 1752.[c] The year 1752 was thus a short year (355 days) as well.


The conclusion is simple, don't use date(1) for dates before 14th September 1752.

Note that I have also reverted from upstream tree the last change (leap years calculation as introduced for bug #1507271). cal(1) is pretty old and all  versions use this semantic.

Maybe you need to open bug for date(1).

Comment 5 Leslie Satenstein 2017-12-17 14:09:31 UTC
Yes, cal is incorrect, So we blame date.

The gregorian calendar (ISO Julian date, plus whatever, went into effect in 1582 October.

Look up wikipaedia.  If the date shown by cal is wrong for 1752 then cal cannot be trusted for any other function before 1753

There are researchers that would like to see the calendar for dates before 1753 and would appreciate having a correct cal program.

Comment 6 Karel Zak 2017-12-19 11:58:46 UTC
Leslie, the gregorian calendar has not been adopted everywhere in 1582 (!)

Not sure why, but cal(1) follows British Empire (Protestants), where the years of the change is 1752

[ And in another years in another countries, see "Adoption of the Gregorian Calendar" https://en.wikipedia.org/wiki/Gregorian_calendar ]

cal(1) behavior is well documented in the man page. There is nowhere promised that it uses gregorian calendar for old dates.

This cal(1) behavior is 25 years old, it's also implemented by cal(1) on another systems (e.g. SunOS): https://docs.oracle.com/cd/E19683-01/816-0210/6m6nb7m5e/index.html


Anyway, maybe we can improve cal(1) to be more flexible, my suggestion:

 * keep the current default behavior (Gregorian since 1752)

 * add option --gregorian to strictly use Gregorian calendar for all dates with no exceptions (it means dates from year 0 to now, no exceptions for 1582 or 1752)

 * for --gregorian also use ISO leap years calculation for all dates

 * add to the man page section about Gregorian and Julian calendars and explain where and when Gregorian calendar went into effect (just to avoid discussions:-)

 * later (after warning in release notes) we can make --gregorian as the default

Do is make sense?

Comment 7 Karel Zak 2017-12-19 13:04:38 UTC
Sorry, for typos...

Comment 8 Karel Zak 2017-12-20 17:39:28 UTC
BTW, the current behavior is also defined by POSIX :-)
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cal.html

Comment 9 Leslie Satenstein 2017-12-25 07:09:37 UTC
Karel, I would say it is a good option. 

What is important, is that working backwards from today  to 1583 to be contiguous day/month and consistent with the 400/100 leapyear rule in effect. 

We can request a document change to cal and to date man pages to highlight the differences. 

My own gregorian/julian calendar routine is based on the October 1582 date missing 10 days. But everything after 1583  with cal --gregorian should match.

Go for it. 

Posix follows the Protestant rule. 

For other info.
For what it is worth, Russa did not adopt the gregorian  calendar for trade until the 1900's. As far as I know their religious calendar is still off by 10 days.
Little Christmas (Jan 6) is used the for the Russian Orthodox calendar.

Thanks in advance.

Comment 10 Karel Zak 2018-07-18 13:25:44 UTC
Note that since version v2.32 cal supports a new command line options 
--iso   
    Display the proleptic Gregorian calendar exclusively

--reform <1752|gregorian|iso|julian>
    This option sets the adoption date of the Gregorian calendar reform.

For more details see: http://man7.org/linux/man-pages/man1/cal.1.html

Comment 11 Leslie Satenstein 2018-07-18 15:37:38 UTC
Thank you Karel.

Much appreciated.


Note You need to log in before you can comment on or make changes to this bug.