Talk:Julian calendar

Rationale of my most recent change

I want the additional day to be added at the beginning of March every 100-but-not-400 years. The way the page was before, the day would be added at the beginning of January. Please check my edit because there is a good chance I messed something up. I💖平沢唯 (talk) 07:44, 27 November 2022 (UTC)

I just realised that it still wrong, but much closer. The actual day skip is when the Julian calendar reaches 29 February every 100-but-not-400 years. I will try to fix it but I’m not very good at this I💖平沢唯 (talk) 07:56, 27 November 2022 (UTC)

We recognise your good faith in trying to correct an error but you need to use this talk page to explain your analysis of the problem and then explain how your new code fixes it. Your 07:44 (UTC) message describes the error (it would be better if it said what causes the error) but you have yet to show how your alternative code fixes it. In all probability it is correct but [in my own (bitter) experience] being required to explain it does a great job of verifying it. A few worked examples would help. --𝕁𝕄𝔽 (talk) 10:39, 27 November 2022 (UTC)

As an example of proper calendar code development, Dershowitz and Reingold in the several editions of their Calendrical Calculations tested all their calendar algorithms for at least ± 10,000 years from the present. Jc3s5h (talk) 14:49, 27 November 2022 (UTC)

Originally, the code for the Julian calendar was just the current date minus 13. I then changed it so that every 100-but-not-400 years, the number 13 would be increased by 1. For example, at the beginning of 2100 it would become 14, then in 2200 it would become 15, and so on. I then changed it again so that this extra day would be added at the beginning of every March on a century common year. But the extra day actually gets added about two weeks later, when the Julian calendar reaches 29 February, so I’m gonna change it again to reflect that. I don’t have prior experience with this so I’m definitely not doing this in the best possible way. If someone else wants to do it instead then please tell me I💖平沢唯 (talk) 02:09, 28 November 2022 (UTC)

Ok I'll explain what I tried to do. I coded it so that if the current year is not divisible by 100, or if it's divisible by 400, or if the Julian date is past February, the Julian date is just the same formula that was on this page before, which is this: [current date - 13 - ((current year-2000)/100 - (current year-2000)/400)]. If the current year is divisible by 100 but not 400, then it checks whether the [current date + 3 - (current year/100 - current year-/400)] is 1 March. If it is, then the Julian date is 29 February. If it's not then the formula is the same as usual except for 12 instead of 13, like this: [current date - 12 - ((current year-2000)/100 - (current year-2000)/400)]. I also moved all of this to Template:JULIANCALENDAR. I know I'm terrible at explaining it but please read over that and tell me if I did something wrong I💖平沢唯 (talk) 03:38, 28 November 2022 (UTC)

I invoke the No original research policy. I insist that any code that is more than a trivial calculation (such as subtracting 13) be taken from a source that satisfies the Identifying reliable sources guideline and a citation be provided to the original source. The citation could be placed either in this article or, if implemented as a template, in the template. Jc3s5h (talk) 03:51, 28 November 2022 (UTC)

What if I change it to be based on this? I💖平沢唯 (talk) 05:24, 28 November 2022 (UTC)

That would be a suitable reliable source; indeed, it's one I have saved on my computer. But I suggest searching the existing templates to see if there is one that is suitable. Also, modules can be written in Lua; maybe the Lua language already has support for Julian calendar dates. Experience dealing with people who come to calendar related articles such as Julian calendar and Julian day indicates that people try to implement an algorithm in the article and find that their version disagrees with the article version, so they "fix" it. It almost always turns out that they didn't understand some aspect of calendrical computing, such as floating point division vs. integer division, that Julian days start at noon, or the like. It takes a lot of work to convert a calendar algorithm from one computer language to another, and just as much work to document what you did so other editors will refrain from deleting it. Jc3s5h (talk) 14:27, 28 November 2022 (UTC)

I don’t see one on the category ‘Date-computing templates based on current time’. I’m gonna try to make one based on the link I sent you (though if you want to do it instead then please do). Also, your last revert messed up the page, so please return this page to the template I made or to how it was originally until this is resolved I💖平沢唯 (talk) 04:33, 29 November 2022 (UTC)

Done I💖平沢唯 (talk) 06:05, 30 November 2022 (UTC)

Why is a new template needed?

Why is a new template ({{JULIANCALENDAR}}) needed? The following should work. {{extract}} uses Module:Age which uses Module:Date.

• {{extract|currentdate}} → 14 September 2024 (Today, Gregorian)
• {{extract|juliandate|julian|{{extract|currentdate|show=juliandate}}}} → 1 September 2024 (Today, Julian)

Johnuniq (talk) 09:02, 30 November 2022 (UTC)

and if we are going to have it (and I can just about see the point) then if anyone is to find it, it should replicate the naming convention and style of similar templates, like {{Today/AD/AH}}, {{Today/AD/SH/AH}}, {{Today/CE/AM}}. (See Hijri calendar, Solar Hijri calendar, Hebrew calendar for use in context.) --𝕁𝕄𝔽 (talk) 10:37, 30 November 2022 (UTC)

It appears the extract template would do the job. I notice the only category this template is in is "Lua-based templates". That might explain why no one found it. I notice the source code for the Date template, which extract calls, has mention of Claus Tøndering's website. I consider the calendar portion of his website reliable for my own use, although I don't know if it would fulfill Wikipedia's guideline for self-published sources. I've seen his work cited on works that are clearly reliable, although I can't bring one to mind at the moment.

But whatever reliable sources may have been used in the Dates module, they are not mentioned in the documentation. Also, the documentation for extract does not mention what modules it calls, nor does it mention what reliable sources it is directly or indirectly based on. Jc3s5h (talk) 13:52, 30 November 2022 (UTC)

You are correct that Module:Date relies on the formulas at tondering.dk. I tested various things including a Python date library and found that some formulas worked only for an entirely practical but very limited range of dates whereas those at tondering.dk worked for all dates with a four-digit year (−9999 to 9999). More important than the source that a particular implementation claims to use are the questions (1) is the implementation correct? and (2) has the implementation been thoroughly tested? I have tested the Module:Date procedures using scripts but as a matter of interest it is possible to spot check dates like this:

• {{extract|juliandate|{{extract|31 March 1700|show=juliandate}}}} → 31 March 1700
• {{extract|juliandate|julian|{{extract|31 March 1700|show=juliandate}}}} → 20 March 1700

The first example confirms that 31 March 1700 Gregorian can be converted to a Julian date and back again. The second example shows that the same day had an 11-day difference in the Julian calendar. Johnuniq (talk) 06:38, 1 December 2022 (UTC)

Describing the divergence from Gregorian

I think saying that the calendars get a day further apart "every 128 years" is confusing, and in fact without saying "on average" afterwards, pretty much incorrect. (For that matter, I may have missed something ... why 128 not 133?) Wouldn't it be simpler to say that it gets one more day out once each century except every fourth one, i.e. whenever the Gregorian calendar skips a leap year. Then the next sentence makes so much more sense (that the difference is 13 days from 1901 to 2099), and people can easily see that the difference will be 14 days in the 2100s, 15 in the 2200s, etc. which is pretty easy reckoning.123.243.8.208 (talk) 23:45, 26 January 2023 (UTC)

That makes sense to me. Anyone want to defend the status quo? --𝕁𝕄𝔽 (talk) 17:12, 27 January 2023 (UTC)

Doing a quick check on what the average is, I made this table.

Greg	Jul	A-B
Jan 1, 1600	Dec 22, 1599	10
Dec 31, 2799	Dec 12, 2799	19
diff		9
1200/9 =	133.3333333

Notice the time span is 1200 years, an integer multiple of the period of the Gregorian civil calendar, 400 years. So why wouldn't the divergence, on average, be 1 year every 133? Jc3s5h (talk) 19:27, 27 January 2023 (UTC)

I think it would be clearer to describe the rate of divergence in a way that relates to its cause. Thus say "three days every 400 years". John Sauter (talk) 18:47, 27 January 2023 (UTC)

I will take that as consensus for the suggested change and will use JS's proposed text. --𝕁𝕄𝔽 (talk) 17:24, 28 January 2023 (UTC)

and then when I went to do it, I thought, hang about, "gains three days" versus what? The preceding sentence is talking about the average tropical year not the Gregorian year, so what we really want to say is by how much it drifts wrt sidereal time – by how much is its 21 March adrift of the March equinox? Right now, the most common date for the equinox is 20 March Gregorian => 9 March Julian.

Is this calculation correct?

• 365*3+366 = 1,461 (= four years); 1,461*100 = 146,100 (400 years)
• 365.24219*400 = 146,096.876 (400 years)
• Difference 96.876 = 3 days 21 hours => best part of four days.

What have I missed? --𝕁𝕄𝔽 (talk) 17:51, 28 January 2023 (UTC)

When I multiply 365.2419 by 400 I get 146,096.76. 400 Julian years is 146,100 days, and 146,100 - 146,096.76 = 3.24, so the Julian year gains 3.24 days on the tropical year every 400 years. 400 Gregorian years, being 3 days shorter, gains 0.24 days. John Sauter (talk) 05:09, 29 January 2023 (UTC)

See our Tropical year article for values for the tropical year; I have reverified the values taken from Richards (p. 587) cited in that article. Looking at the table in Richards, if I wanted to state a value for the length of the tropical year representative of the period 500 to 2000 (astronomical year numbering) I would write 365.2422 ephemeris days (each day comprising 86,400 SI seconds). I would not write more than 4 digits after the decimal point, nor would I apply it before the year 500.

Sidereal time has nothing to do with it. Jc3s5h (talk) 17:41, 29 January 2023 (UTC)

OK, taking 365.2422 for the number of days in the tropical year, 365.2422 × 400 = 146,096.88 days in 400 tropical years. The number of days in 400 Julian years is ((365 × 3) + 366) × 100 = 146,100, so the Julian calendar gains 146,100 - 146,096.88 = 3.12 days on the tropical year. In the Gregorian calendar, 400 years is 3 days shorter, so gains only 0.12 days on the tropical year. John Sauter (talk) 18:48, 29 January 2023 (UTC)

The crudest way to analyze error propagation is to keep track of the number of significant figures. Since 365.2422 has seven significant figures, the number of days in 400 tropical year should be stated as 146,096.9. The gain of the Julian calendar would then be stated as 3.1 days and the gain of the Gregorian calendar is 0.1 days. Given the fuzziness of what period we're interested in, a more sophisticated analysis is not warranted. Jc3s5h (talk) 19:10, 29 January 2023 (UTC)

Ok, I will try again with that. (Excuse my lazy use of sidereal time, I was focused on the March equinox as a reference point.) --𝕁𝕄𝔽 (talk) 21:28, 29 January 2023 (UTC)

Sorry, few will take the time to read it all through, here or in the article (I won't). The current 13 days difference between Julian and Gregorian is essential and must be much better highlighted (it gets lost in the looong paragraph), and the (approximate) number of years it takes for it to grow by yet another day (on average, I guess). Once we indicate these 2 figures, every user will understand the fact that it grows constantly and by what rate, more or less. Anything more than that is fodder for math buffs who want to redo the calculation by themselves, in other words: too much for Wiki, IMHO. Cheers, Arminden (talk) 12:03, 30 January 2023 (UTC)

PS: please check if the quasi-algorithm I've added at the end is accurate. I think it is, and it offers a concise and useful conclusion. Thanks, Arminden (talk) 12:06, 30 January 2023 (UTC)

Add a link to calendar?

1. The ingress of the article does currently not link to the calendar article. I suggest adding a link to the calendar article.

2. The article starts with a brief history of the subject. I think the article should start with a short description/definition instead.

Unable to edit myself because not registered user. 2001:2020:31B:DCE2:1D11:2C6E:DC4E:7371 (talk) 22:33, 12 February 2023 (UTC)

1. I agree in principle, but the lead does link to the Roman calendar article, which in turn links to the calendar article, and that looks good enough to me.

2. I agree. Done. User shouldn't be forced to read through long paragraphs to get to the definition. Arminden (talk) 09:52, 13 February 2023 (UTC)

Yes, fair point. How about this as first two paras:

The Julian calendar is a solar calendar of 365 days in every year with an additional leap day every fourth year (without exception). The Julian calendar is still used in parts of the Eastern Orthodox Church and in parts of Oriental Orthodoxy as well as by the Berbers.

This calendar, proposed by Roman consul Julius Caesar in 46 BC, was a reform of the earlier Roman calendar. It took effect on 1 January 45 BC, by edict. It was designed with the aid of Greek mathematicians and astronomers such as Sosigenes of Alexandria.

Better? --𝕁𝕄𝔽 (talk) 09:59, 13 February 2023 (UTC)

References

Modern usage. Eastern Orthodox

In Ukraine, the two largest churches (OCU and UGCC) decided to celebrate Christmas on December 25 according to the new style (Gregorian and Revised Julian calendars), so it is worth removing Ukraine from the list of countries that celebrate religious holidays according to the Julian calendar. 92.253.239.82 (talk) 13:32, 25 May 2023 (UTC)