Talk:Julian day/Archive 4

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Proleptic Gregorian calendar

The article shouldn't give an algorithm that converts dates into theProleptic Gregorian calendar. Julian days were invented by astronomers and they use the Julian calendar for dates before the invention of the Gregorian calendar in 1582. You wouldn't have to note that the JDs converted with this algorithm won't match those in ephemerides if you used the mainstream, historically accurate Julian/Gregorian calendar. An algorithm for doing these conversions correctly can be found in Astronomical Algorithms by Jean Meeus. Senor Cuete (talk) 15:05, 15 September 2017 (UTC)

Well, the thing is, any algorithm for converting Julian day to a Gregorian date will also be correct for proleptic Gregorian dates! What can you do about it? Eric Kvaalen (talk) 15:52, 15 September 2017 (UTC)

The title of the Algorithm is "Converting Julian or Gregorian calendar date to Julian day number", so no, this is not an algorithm to convert FROM a Julian date, it's an algorithm to convert TO a Julian data. You say: "any algorithm for converting Julian day to a Gregorian date will also be correct for proleptic Gregorian dates". No it won't. Algorithms used by astronomers will convert a JD correctly to either a Julian or Gregorian date. Astronomy books like Meeus, don't even acknowledge the existence of the Proleptic Gregorian calendar. Then it says: "It is worth noting that this algorithm does not follow the NASA[31] or the US Naval Observatory[32] – the convention in these systems being that the Gregorian calendar did not exist before the date October 15, 1582 (Gregorian). This algorithm effectively back-dates the Gregorian calendar onto the Julian calendar for dates before the introduction of the Gregorian calendar. Thus any calculations made with this formula before October 15, 1582, will not agree with these previous ephemerides." This is apparently wrong since the algorithm gives different steps for converting from either Gregorian or Julian dates. Shouldn't this text be removed? Also an algorithm like Meeus has a statement that corrects for either Gregorian or Julian dates so it doesn't require the user to know which system he is using. Senor Cuete (talk) 16:25, 15 September 2017 (UTC)

Is this algorithm from Tøndering? In programming you would check for dates from the missing ten days in October 1582 and report an error. Senor Cuete (talk) 17:11, 15 September 2017 (UTC)

@Senor Cuete: But your original statement was that the article shouldn't give an algorithm that converts dates INTO the Proleptic Gregorian calendar! (And it does -- in the section called "Julian or Gregorian calendar from Julian day number".) Eric Kvaalen (talk) 18:56, 15 September 2017 (UTC)

There's another issue with the proleptic Gregorian calendar. How do you determine the day of the week? In the Julian calendar October 4 1582 is a Thursday. The next day is October 15, Friday. If you revise the days of the week as you do the dates in the proleptic Greorian calendar, October 4 would be a Monday. your algorithm for finding the day of the week won't work for proleptic Gregorian dates if this is how it works. I've been asking people who advocate the use of this revisionist calendar how this works for many years and nobody seems to know. The article about the proleptic Gregorian calendar doesn't mention this. Senor Cuete (talk) 16:46, 30 September 2017 (UTC)

Issues such as this are most easily understood by having a way to designate an absolute date, which is exactly what Julian days are for. So here is a table that includes the day of the week

JD	(proleptic) Gregorian calendar date	Julian calendar date	Day of week
2299163.0	17 October 1582	7 October 1582	Sunday
2299162.0	16 October 1582	6 October 1582	Saturday
2299161.0	15 October 1582	5 October 1582	Friday
2299160.0	14 October 1582	4 October 1582	Thursday
2299159.0	13 October 1582	3 October 1582	Wednesday
2299158.0	12 October 1582	2 October 1582	Tuesday
2299157.0	11 October 1582	1 October 1582	Monday
2299156.0	10 October 1582	30 September 1582	Sunday
2299155.0	9 October 1582	29 September 1582	Saturday
2299154.0	8 October 1582	28 September 1582	Friday
2299153.0	7 October 1582	27 September 1582	Thursday
2299152.0	6 October 1582	26 September 1582	Wednesday
2299151.0	5 October 1582	25 September 1582	Tuesday
2299150.0	4 October 1582	24 September 1582	Monday

So, the same absolute date has the same day of the week, whichever calendar it is expressed in. Jc3s5h (talk) 17:55, 30 September 2017 (UTC)

No you are wrong. On my C compiler, October 4, 1582 (JD 2299160) using the formula you give in the article: int W1 = (2299160 + 1) % 7 evaluates to 4, Thursday. What you say would be correct *IF* the days of the week are all revised to be continuous with the later Gregorian calendar. Think about it how can removing ten days agree with modulo seven? Senor Cuete (talk) 18:55, 30 September 2017 (UTC)

October 4, 1582 - int W1 = (2299161 + 1) % 7 evaluates to Friday. Using the algorithm in the the article the days of the week are only contiguous if you use the Julian/Gregorian transition. So, which is it? Senor Cuete (talk) 19:04, 30 September 2017 (UTC)

Using the algorithm in the Finding day of week given Julian day number section for JDN 2299160 (which is October 4, 1582, Julian calendar, and also October 14, 1582, Gregorian proleptic calendar) does indeed evaluate to 4, which is Thursday. If you read Inter gravissimas you will see that Pope Gregory XIII did indeed order that the the day after Julian calendar October 4, 1582, a Thursday, was a Friday, and it's calendar date in the new Gregorian calendar was October 15, 1582. (Gregory does not say this in so many words, but it can be figured out from the statement "and then shall come XVI calends November [October 17th], the office and the mass of the 18th Sunday after Pentecost". (Gregory XIII 1582)

Your expression "October 4, 1582 - int W1 = (2299161 + 1) % 7" makes no sense to me and I cannot understand anything after that in your post. Jc3s5h (talk) 19:29, 30 September 2017 (UTC)

The '%' operator in C is modulo. Using the formula in the article - JD 2299160 is a Thursday and 2299161 is a Friday. 2299160 is October 4 and 2299161 is October 15. "W1 = (2299161 + 1) % 7" makes no sense to me" so read the article. This is exactly the formula given. Gregory is saying that the days of the week shall continue un-broken. Your chart says that 4 October 1582 - is a Monday so you have revised the days of the week in the proleptic Gregorian calendar in your chart. So the days of the week are NOT the same in both calendars. Senor Cuete (talk) 20:41, 30 September 2017 (UTC)

I'm going to dissect your post phrase by phrase and stop at the first problem.

• "The '%' operator in C is modulo." Agree.
• "Using the formula in the article - JD 2299160 is a Thursday and 2299161 is a Friday." Agree.
• "2299160 is October 4". You failed to state whether you mean October 4 in the Julian calendar or proleptic Gregorian calendar. Your posts have been confusing because you have not been clear about which calendar a particular date is in. So I stopped reading your post at this point. Jc3s5h (talk) 21:11, 30 September 2017 (UTC)

Obviously 2299160 is a date in the Julian calendar. 2299161 is in the Gregorian calendar. These are a Thursday and a Friday. 2299161.0 Your table gives 2299161.0 as:

15 October 1582 Gregorian

5 October 1582 Julian

This is wrong because the 4th is followed by the 15th as per Pope Gregory's decree. Senor Cuete (talk) 22:40, 30 September 2017 (UTC)

Many countries ignored Gregory's decree. Even in Catholic countries, they weren't always able to arrange to make the change by October 15. The Julian calendar is still in use in some religions, and occasionally by astronomers. Jc3s5h (talk) 23:06, 30 September 2017 (UTC)

No, you are absolutely wrong. The Julian calendar is always used by astronomers for dates before the adoption of the Gregorian calendar. The books I have about astronomical algorithms don't even acknowledge the existence of the proleptic Gregorian calendar. But back to the original problem. the algorithm for the day of the week doesn't work for dates in the proleptic Gregorian calendar. Senor Cuete (talk) 23:45, 30 September 2017 (UTC)

The algorithm for the day of the week in the Finding day of week given Julian day number section is only a function of the Julian day number. Since the proleptic Gregorian calendar date isn't in the algorithm, it can't affect the correctness of the algorithm.

Perhaps it isn't clear to you that the proleptic Gregorian calendar, the Julian day number, and the day of the week are all continuous. So at JD 2299161.0 it was noon, Friday, October 15, 1582, Gregorian calendar. Twenty-four hours before that, it was JD 2299160.0, noon, Thursday, October 14, 1582, proleptic Gregorian calendar. Twenty-four hours before that, it was JD 2299159.0, noon, Wednesday, October 13, 1582, proleptic Gregorian calendar. And so on. Jc3s5h (talk) 00:02, 1 October 2017 (UTC)

Believe me, I completely understand all of this - I'm responsible for software that has to do these calculations correctly. Yes the proleptic Gregorian calendar does impact this because a date in the proleptic Gregorian calendar evaluates to a different JD than a date in the historically accurate Julian calendar but whatever, I'm tired of trying to explain this. Remember, you are not writing this for me, you're writing this for people who don't know about this and are reading an encyclopedia article about it. Senor Cuete (talk) 01:10, 1 October 2017 (UTC)

I follow what Jc3s5h is saying, but not Cuete. The day of week formula accepts only one parameter, the Julian day number. It does not matter what the calendar date is, or which calendar is in use. Given the information in the article, two operations are required to obtain the day of week from a calendar date. To use a single operation would make the Julian day number irrelevant. Therefore, the statement "the algorithm for the day of the week doesn't work for dates in the proleptic Gregorian calendar" makes no sense. --Nike (talk) 11:15, 1 October 2017 (UTC) (JD 2458027.96875)

Your new revision of the article says "The algorithm is valid for all Gregorian calendar dates after November 23, −4713." There aren't any Gregorian calendar dates before 10/15/1582. These would be dates in the troublesome proleptic Gregorian calendar. Shouldn't the note include something like: "(Proleptic Gregorian calendar before October 15, 1582").

True, I'll take a look. Jc3s5h (talk) 23:06, 30 September 2017 (UTC)

Bibliography for Proleptic Gregorian Calendar

References

Gregory XIII (March 20, 2002/February 24, 1582). "Inter Gravissimas". Bill Spencer, trans. Retrieved from http://www.bluewaterarts.com/calendar/NewInterGravissimas.htm.

Reversion

@Jc3s5h: Hi. You just reverted my edit, with the comment:

"The algorithm is valid for all Julian day numbers" is false. Edits give impression JD can't be computed for the morning hours.

First of all, why do you say that that algorithms are not valid for all Julian day numbers? Both the Julian and the Gregorian calendars are well defined, so the algorithms will definitely work. There's no need for the JDN to be positive. Of course, these calendars were not used before JDN 0 but that's another matter.

Secondly, it's true that those algorithms don't work for morning hours, because they give the JDN for the afternoon, which is 1 more than the value we want! That's what I was trying to explain.

Eric Kvaalen (talk) 12:21, 15 September 2017 (UTC)

According to the cited source "The algorithm works correctly for all dates after 4800 BC, i.e. at least for all positive Julian Day." I have tested several algorithms of this type (although I don't seem to be able to locate a test of this exact algorithm). They all fail for Julian dates much less than 0. I invite you to implement it yourself and put it to the test for the minimum useful date, such as the date of the big bang.

It's true the algorithms don't explicitly mention the procedure to allow for the differences between the convention of Julian days beginning at noon and the date & time of day in a particular time zone. Feel free to explain the procedure. But it isn't appropriate to imply morning hours can't be converted. Chances are the date and time of day to be converted isn't even in UTC, but rather, some other time zone, so it isn't even correct to talk about morning hours. Jc3s5h (talk) 12:56, 16 September 2017 (UTC)

The method of Peter Baum works for negative JDs (converts a Julian day number to a calendar Date including JD < 0): https://web.archive.org/web/20140910060704/http://mysite.verizon.net/aesir_research/date/date0.htm Baum's method is similar to the method of Meeus. The difference is in the last line. As I recall, Baum says that reducing the results in Meeus by some simple operation like floor(), (int) or round() would make Meeus' method work for negative JDs. Senor Cuete (talk) 15:50, 16 September 2017 (UTC)

Jc3s5h, I don't understand. What do you mean when you say you tested several algorithms? How can you tell that they give incorrect results? Let's say the Big Bang was on January 1, in the year −14,000,000,000 (which is 14,000,000,001 BC), Julian calendar. Then according to the algorithm in our article, I get:

a = floor((14−1)/12) = 1

y = −14,000,000,000 + 4800 − a = −13,999,995,201

m = 1 + 12a − 3 = 10

JDN = day + floor((153m+2)/5) + 365y + floor(y/4) − 32083 = 1 + 306 − 5,109,998,248,365 − 3,499,998,801

JDN = −5,113,498,246,859

Looks good to me!

I will try to rephrase my edit a bit.

Eric Kvaalen (talk) 15:24, 17 September 2017 (UTC)

The year -14,000,000,000 is evenly divisible by 400; it is 14,000,002,000 years before 1 January 2000. Finding the number of 400 year cycles, 14,000,002,000 / 400 = 35,000,005. The Gregorian calendar repeats every 400 years (except for the date of Easter and other lunar calculaitions,which do not concern us) which means every 400 year period contains exactly 365*400 + 97 = 146,097 days. So the period from 1 January -14,000,000,000 to 1 January 2000 contains 146,097 * 35,000,005 = -5,113,395,730,485 days. Many sources could be used to show noon 1 January 2000 is JD 2,451,545. Subtracting 5,113,395,000,000 from 2,451,545 gives -5,113,393,278,940. Your computation gave -5,113,498,246,859, which is much different. Jc3s5h (talk) 19:08, 17 September 2017 (UTC)

I just noticed that Eric Kvaalen mentions Julian calendar. For the Julian calendar, if I follow a similar line of reasoning, and take notice that 100 Julian calendar years always contains exactly 36,525 days, and the JD of noon, 1 January 2000, Julian calendar was 2,451,558, I find the JD of noon, 1 January -14,000,000,000 was -5,113,498,278,942. This is also quite different than Eric Kvaalen's evaluation of the algorithm from the article. Jc3s5h (talk) 20:06, 17 September 2017 (UTC)

I would add that the definitions of Julian day number and Julian Date are taken straight from the IAU and I consider it unwise to alter them. (A republication of the IAU resolution by the IERS is cited in the article.) Jc3s5h (talk) 20:24, 17 September 2017 (UTC)

You can test to see if the JD -1 is a day less than the year zero. Senor Cuete (talk) 20:47, 17 September 2017 (UTC)

Julian dates around the year -1 are about 1,720,700. The JD -1 should be no where near the year zero. Jc3s5h (talk) 21:11, 17 September 2017 (UTC)

NO shit! Use your algorithm to convert the JDs of 0 and -1. If the YMD of JD-1 is not one day less than 0 your algorithm is not valid for negative JDs. Use a YMD of the day before JD0 in your date to JD algorithm. If the JD isn't -1 then your algorithm isn't valid for negative JDs. Senor Cuete (talk) 01:36, 18 September 2017 (UTC)

Jc3s5h, it's just that I forgot to subtract the 32083. It should say:

JDN = day + floor((153m+2)/5) + 365y + floor(y/4) − 32083 = 1 + 306 − 5,109,998,248,365 − 3,499,998,801 − 32083

JDN = −5,113,498,278,942

Eric Kvaalen (talk) 07:15, 18 September 2017 (UTC)

In that case, I'll give the algorithms a more extensive test. The problem is, though,that even if they pass my tests, we still won't have a statement in a reliable published source stating they're valid for all calendar dates. Jc3s5h (talk) 11:26, 18 September 2017 (UTC)

But Jc3s5h, there's no point. First of all, as I said, you have no way to check. What you did yesterday was simply to use your knowledge of the length of a century in the Julian calendar. Well, for sure the algorithm gives the right value for that. So you can check to see whether the algorithm gives the right difference for various numbers of Julian-calendar centuries, but you'd just be wasting your time. Secondly, it's clear that the algorithm will work, because as I have said before both the Julian and the Gregorian calendars are very regular and precisely defined. There's nothing that will suddenly cause a glitch at some point in the distant past. No need for Hamlet to proclaim, "The time is out of joint!"

So I disagree with your most recent edits putting back in those caveats. They're totally useless. We are not obliged to say that the algorithm might not work in the past just because those authors didn't say that it does! It just makes our article look stupid.

Eric Kvaalen (talk) 05:59, 19 September 2017 (UTC)

Eric Kvaalen wrote 'Secondly, it's clear that the algorithm will work, because as I have said before both the Julian and the Gregorian calendars are very regular and precisely defined. There's nothing that will suddenly cause a glitch at some point in the distant past. No need for Hamlet to proclaim, "The time is out of joint!"' Wouldn't that argument apply equally well to all the other algorithms, in the article?

In the case of Richard's algorithm for converting a Gregorian calendar date to a Julian day number, I had already implemented it in PHP for another project, and knew it failed for dates in the distant past. Just to be sure, I reimplemented in Excel (being careful to use the QUOTIENT function rather than regular division with "/") and confirmed it works for noon January 1, 2000 (= JDN 2451545). I obtained the following results for 400 years before JDN 0 (using the Gregorian calendar):

Gregorian calendar date to test				correct Julian date
year	-5113			-146097
month	11
day	24
Algorithm parameters
y	4716		v	3
j	1401		u	5
m	2		s	153
n	12		w	2
r (ar)	4		B	274277
p	1461		C (AC)	-38
step
1	f =	-144735
2	e=	-1736817
3	g=	0
4	h=	2
5	d=	1
6	month=	3
7	year=	-438920

The reason for this is that if you read Richard's book, which contains a more complete description of the algorithm, you will find it is only intended for non-negative JDNs, and he only defines the behavior of the mod function when both arguments are positive. Excel accepts negative arguments for the mod function, but Richards never contemplated that situation (or, at least, didn't write about it). I will add a citation to Richard's book. Jc3s5h (talk) 12:38, 19 September 2017 (UTC)

Sorry, Jc3s5h, I don't understand. Are you saying that your calculation gives a wrong answer, or what? I don't understand why it says year=-438920 at the end. And what does this have to do with the algorithm in our article, which I used up above? Eric Kvaalen (talk) 14:21, 21 September 2017 (UTC)

I'm saying that that Richard's algorithm for converting a Gregorian date to a Julian day number gave an incorrect result for a date 400 years before JDN 0. It's relevant to the algorithm given at the beginning of the thread because it shows that just because it's possible in principle to convert to or from negative JDNs, that's no guarantee any particular algorithm will do so correctly. We shouldn't say an algorithm works for all dates unless we have a reliable source that says so.

In addition, you made an edit which removed an explanation in a footnote that Richards didn't state the range of validity of the algorithm that I provided the calculation for. That's true for the version of the algorithm in the Explanatory Supplement to the Astronomical Almanac. It turns out the explanation was appropriate, because the longer version explanation of the algorithm in Mapping Time states it's only valid for non-negative JDNs, and because the calculation I provided proves it fails for a particular negative JDN. Jc3s5h (talk) 14:49, 21 September 2017 (UTC)

But Jc3s5h, why do you say that your calculation for 400 years before JDN 0 gave an incorrect result? All I see is a final line that says year=-438920, which doesn't make any sense. It's not even a JDN. Eric Kvaalen (talk) 05:53, 23 September 2017 (UTC)

Sorry, I described the algorithm incorrectly. It's Richard's algorithm to convert a JDN to a Gregorian calendar date. The input is the JDN -146097. The output should be year -5113, month 11, day 24. The actual output is year -438920, month 3, day 1. Jc3s5h (talk) 11:39, 23 September 2017 (UTC)

Well Jc3s5h, you made three mistakes. First of all, f should be −144737. I don't know how you got −144735. Secondly, when you calculated e you multiplied by 12 instead of by 4. And finally, when you calculated Y you divided by 4 instead of by 1461. If you correct these three errors, you get D=24, M=11, and Y=−5113. There's no problem with this algorithm except maybe that it's overly complicated. Eric Kvaalen (talk) 15:48, 24 September 2017 (UTC)

I found one error, where I gave names to the cells in Excel and one of the cells had the wrong name.

I still find the value of f=-14435 to be correct. Using = in the computer programming sense of "assign the value on the right to the variable on the left" rather than "equals",

f = -146097 + 1401 + (((4 × J + B) div 146097) × 3) div 4 + C

which is -146097 + 1401 + (((4 * -146097 + 274277) div (-146097)) * 3) div 4 + (-38)

which is -146097 + 1401 + ((-310111 div (146097)) *3) div 4 + (-38)

which is -146097 + 1401 -2 *3 div 4 + (-38)

which is -146097 + 1401 -1 + (-38)

which is -144735

When the correction is put into the spread sheet the new results are

Gregorian calendar date to test				correct Julian date
year	-5113			-146097
month	11
day	24
Algorithm parameters
y	4716		v	3
j	1401		u	5
m	2		s	153
n	12		w	2
r (ar)	4		B	274277
p	1461		C (AC)	-38
step				JD
1	f =	-144735		-146097
2	e=	-578937
3	g=	270
4	h=	1352
5	d=	26
6	month=	11
7	year=	-5112

So now the day, month, and year are not absurd values, but the year and day are wrong.

— Preceding unsigned comment added by Jc3s5h (talk • contribs) 17:51, 24 September 2017 (UTC)

Jc3s5h, I see what the trouble is. It's the definition of "div", or rather the lack of a definition. I did it in Excel using the FLOOR function. (I didn't remember that you said there was a QUOTIENT function.) The FLOOR function rounds down, which means away from zero if the argument is negative. With DIV it's not necessarily defined. For instance, in the C language, it's apparently implementation dependent! If one uses FLOOR, then the algorithm works just fine with negative Julian day numbers. As indeed it must, since as I have said before, the Gregorian and Julian calendars are perfectly regular. They're defined as cyclical systems, with periods of 400 years and 4 years respectively. As long as an algorithm is implemented with functions like FLOOR which don't change their behavior when you cross zero, then everything is fine. I think we should rewrite the section avoiding use of the word DIV, and removing the table with all the constants. We can just write the formulas with the constants plugged in! And we can skip the provisos about negative Julian day numbers. We are not obliged to put every little thing that an author says into our article, especially if it is a bit stupid. (It's stupid to say it might not work, if one uses FLOOR, but it's true if one says "DIV".) Eric Kvaalen (talk) 08:46, 25 September 2017 (UTC)

There is no "DIV" function in C. If you are talking about division, it's written as '/' in C. NO it's not implementation dependent. Senor Cuete (talk) 15:02, 25 September 2017 (UTC)

For anyone unaware of the history here, it used to be, prior to C99. Nitpicking polish (talk) 15:15, 25 September 2017 (UTC)

There is a Div function in C. See this C reference manual, which says that the definition is implementation dependent. But that's beside the point. The point is that Div is not some universally defined function, whereas Floor is. Eric Kvaalen (talk) 13:39, 26 September 2017 (UTC)

I stand corrected. There is a div() function in C which was implementation dependent before C99. BUT this is not what is intended in these algorithms. div() returns a data structure of type div_t. What is intended here is simple division, typed as '/'. Calling this "DIV" is non-standard and confusing. Senor Cuete (talk) 16:06, 26 September 2017 (UTC)

It's just that I went to see whether "div" was well defined for negatvie numbers, and I found a link in C mathematical functions to the C function. The function gives the truncated quotient as well as the remainder (which doesn't interest us), and the manual says it used to be well defined, before C99. The / operator, which is similar to div, was implementation dependent. Actually it's not clear whether div is still precisely defined or not (contrary to what I said yesterday). Eric Kvaalen (talk) 17:18, 26 September 2017 (UTC)

In my experience, there are evil jerks out there who just love to introduce subtle little errors into Wikipedia tables, formulas, and anything mathematical. Thus such materials should be drawn verbatim from reliable sources, so that an editor who knows the jerk for what it is, but who didn't major in computer science at university, will be able to repair the damage by comparing the Wikipedia article to the cited source. I consider it original research to repair a published algorithm, or extended beyond the domain stated in the reliable source. (Sometimes the vandalism involves complicated edit wars with other vandals pilling on, so it's difficult to identify the version before the vandalism.)

The Wikipedia original research policy allows routine calculations but I believe the kind of changes you propose go beyond that.

If you want to provide an algorithm in the article that will work for negative JDNs, I suggest you find a published algorithm that works as-is. I have looked for such an algorithm. The only one I could find was in Dershowitz & Reingold, and that was in terms of their somewhat ill-defined Rata Die so would have needed modification and a complicated explanation to appear here. (Full bibliography entry in article.) Jc3s5h (talk) 11:16, 25 September 2017 (UTC)

@Jc3s5h: You're going too far. Anyone can check whether the constants in a formula are the same as in the source! The way it is now, it's very confusing. It even confused you. And it's obvious that using Floor instead of the ill-defined Div would solve all our problems. Why should we put in a formula that doesn't work if someone interprets it with the wrong meaning of Div?? We want Wikipedia to be a high-quality reference, not something that can easily be misinterpreted, and that says that a formula might not work for negative numbers, when clearly it does if used correctly. Eric Kvaalen (talk) 13:39, 26 September 2017 (UTC)

Eric Kvaalen You say: "...it's very confusing. It even confused you. And it's obvious that using Floor instead of the ill-defined Div would solve all our problems..." Obviously the one who is horribly confused is you. Nothing is "ill-defined" about division. With computers, if the result or a division is an integer, the fractional part is discarded. The point here is to cite an algorithm from a reliable source. You don't get to rewrite it so it makes sense to you. Astronomers have no problem doing these computations. Their methods are simple and they deal with Julian/Gregorian calendar reform correctly, using the Proleptic Julian calendar for dates before the adoption of the Julian calendar. JDs were invented by and used by astronomers. The two standard methods used by astronomers for JD->date and date->JD conversions are the methods of Meeus. Astronomical Algorithms by Meeus is the bible of astronomical computations. It is the basis of the JPL ephemerides. Also this would help banish the Proleptic Gregorian calendar from the article, simplifying it. An example of the use of one of these algorithms on Wikipedia can be found here: https://en.wikipedia.org/wiki/Mesoamerican_Long_Count_calendar#Converting_between_the_Long_Count_and_western_calendars. Senor Cuete (talk) 15:23, 26 September 2017 (UTC)

I will not accept the addition of any algorithm that has not been published in a reliable source. The reliable source says "/". The article currently says "div" because Loadmaster decided this edit would "Clarify integer operators". If you want to change the operator back to "/", I'm fine with that.

While anyone can check if the constants in a formula are the same as in a source, not anyone can check if the various combinations of modulus operations and integer divisions will work for negative JDNs.

Neither the division operator nor the modulus operation are confusing so long as the JDN is non-negative, which is how Richards designed the algorithm, because none of the operands will be negative.

If necessary I will use every dispute resolution mechanism available to prevent the insertion of any unpublished algorithm. Jc3s5h (talk) 14:32, 26 September 2017 (UTC)

Señor Cuete, I agree with you that these calculations are quite straight-forward and are done all the time! That's why I think it's silly to put in a proviso saying that they might not work for negative JDNs. Of course they work, so long as you always round down instead of rounding down for positive and upwards toward zero for negative.

Jc, I propose to get rid of the table of constants and put in a note saying that if you truncate toward zero for negative numbers then the algorithm gives incorrect results. We should also remove the proviso about the algorithm going the other direction (date to JDN). I don't agree to simply replacing div by /. That wouldn't help at all. If you don't agree with what I propose, then please do take it to dispute resolution.

Eric Kvaalen (talk) 18:13, 26 September 2017 (UTC)

The method of Peter Baum is more or less the method of Meeus with the addition of flooring some of the last results. Adding that note might be WP:OR. Why is it necessary to add an algorithm that can deal with negative JDs and how do you propose to deal with the Proleptic Gregorian calendar? Since the JD is an astronomical concept, invented to express times as a number of days since a fundamental epoch, I advocate eliminating it from the article as much as possible. Books like Meeus don't even acknowledge its existence. Senor Cuete (talk) 18:43, 26 September 2017 (UTC)

@Senor Cuete:, Meeus is an amateur astronomer and his books are in no way regarded as "the bible" by JPL, USNO, or Her Magesty's Nautical Almanac Office. For algorithms that might be more or less regarded as "the bible" see the USNO's NOVAS software or the IAU's Standards of Fundamental Astronomy. I've looked at these and didn't think the algorithms were especially suitable for presentation in this article.

@Eric Kvaalen: your arguments do not allow for the possibility that the reader might choose to implement the algorithm with integer arithmetic, rather than floating point arithmetic. Using 64 bit integers would allow a greater range of conversions that are accurate to the day than double-precision floating point. With integer arithmetic, your statements about rounding and floor become meaningless. Jc3s5h (talk) 20:23, 26 September 2017 (UTC)

Your feelings about Meeus are pretty irrelevant and do nothing to resolve the fundamental questions - what (if any) algorithms should be presented in this article? Why is is necessary to provide an algorithm that works for negative JDs? How should the article deal with the Proleptic Gregorian calendar? My answer is use the methods of Meeus, note that they won't work with negative JDs, briefly describe Julian/Gregorian calendar reform and link to other articles about this and don't include the Proleptic Gregorian calendar. The methods of Meeus solve the proleptic Gregorian calendar problem by not supporting it. Senor Cuete (talk) 21:39, 26 September 2017 (UTC)

Reversion: arbitrary break

At 21:39, 26 September 2017 (UTC) Senor Cuete suggested not dealing with the proleptic Gregorian calendar. I consider that less than ideal, because ISO 8601 and standards derived from it call for the use of the proleptic Gregorian calendar in some situations. Also, in countries that never used the Julian calendar, but rather went directly from a traditional local calendar to the Gregorian calendar, it isn't at all obvious that the Julian calendar is more appropriate than the proleptic Gregorian calendar for dates before 1583.

Also, an algorithm that always switches in 1582 is not suitable because many countries that had been using the Julian calendar did not switch to the Gregorian until long after 1582; Greece as recently as 1923. So a choice of algorithms for dates when the calendars overlap is essential. Jc3s5h (talk) 22:01, 26 September 2017 (UTC)

Yes, I agree with that. But back to the subject of integer arithmetic -- Of course the reader should use integer arithmetic. I don't understand what you mean. My statement about rounding and floor is that in order for the algorithm (for JDN to date) to work for negative JDN, we have to interpret, for example, (−6)/4 to be −2, not −1. In other words, Floor(−1.5). Eric Kvaalen (talk) 07:30, 27 September 2017 (UTC)

By integer arithmetic, I mean that the reader is working in a strongly typed computer language, where the type of each variable is declared. When the program is compiled, it eventually leads to the calculation being done by different parts of the computer hardware, either the integer part of the CPU or the floating point unit. For example, in C#,

long A = 3;

long B = 2;

long C;

C = A/B; // C now equals 1

It's useless to invoke the floor function when using integer arithmetic because whatever operand you are providing for the floor function is already an integer.

One problem is the claim that the behavior of some old C compilers was implementation dependent for division involving negative numbers. What is a greater concern is the mod function. I don't know what graduate students in math learn, but in secondary schools and at the undergraduate level outside the math department, the definition of the modulus function for negative numbers simply isn't discussed. Consequently, the definition in various programming languages vary. For example, in C#, the function is called "remainder" and the symbol is "%".

Console.WriteLine(-5 % 2); // result is -1

Console.WriteLine(-5 % -2); // result is -1

In FORTRAN (GNU FORTRAN specifically) there is a MOD function defined as follows:

The return value is the result of A - (INT(A/P) * P). The type and kind of the return value is the same as that of the arguments. The returned value has the same sign as A and a magnitude less than the magnitude of P.

GNU FORTRAN also provides a MODULO function, defined as:

For integer A and P,

MODULO(A,P) has the value R such that A=Q*P+R, where Q is an integer and R is between 0 (inclusive) and P (exclusive).

When you work through the details, you find that these definitions give different results when A and/or P are negative. Richards writes his algorithm to insure the arguments of the mod function are positive, so offers no guidance on which function to choose. Jc3s5h (talk) 12:31, 27 September 2017 (UTC)

All right, now I understand what you meant. It's true that our article at present says "integer division is used exclusively". I think we should take that out, because in the first algorithm (date to JDN) it's not true (it uses normal division followed by Floor), and the second algorithm (JDN to date) has been rewritten (by Loadmaster) using (the unclear) Div instead of /. It would be clearer if we used normal division (not "integer division") followed by Floor for the JDN-to-date algorithm as well, as we do for the date-to-JDN algorithm. That would have the advantage that the algorithm would then work smoothly across zero, in other words it would work for negative JDN. Of course, if someone actually programs this in a language like C (rather than, say, Excel), he will have to think about whether to use long integers instead of double-precision reals, and he will have to make sure that his program does Floor when the result is negative, rather than going to the integer with smaller magnitude.

So what do you say about my proposal of 18:13, 26 September?

Eric Kvaalen (talk) 08:40, 28 September 2017 (UTC)

You are quite right that the presence of / followed by floor indicates floating point division, so if that algorithm is to remain, then the type of division will have to be specified for each algorithm rather than making a general statement at the beginning. The alternative would be to replace the algorithm with one from the Explanatory Supplement to the Astronomical Almanac 3rd ed., which would be a more respected source, but wouldn't work for non-negative JDNs.

Any attempt to alter an algorithm from the published version will go to dispute resolution. Jc3s5h (talk) 09:28, 28 September 2017 (UTC)

There's no reason why we can't write his algorithm in a clearer way, and it would have the added benefit of working for negative JDN. We are not obliged to tell the readers that he says it might not work for negative JDN when in fact you and I know that it does work (if written in the right way, using Floor). So go ahead with taking it to dispute resolution. Here is what I propose, again:

We get rid of the table of constants. We write the second algorithm using Floor and / instead of the ill-defined Div which doesn't work for negative JDN if it is interpreted the way C and Fortran define integer division. We take out the provisos about the algorithms not working for negative JDN.

Eric Kvaalen (talk) 09:57, 30 September 2017 (UTC)

"WE" are not going to include YOUR original research: WP:OR. "WE" aren't going to publish YOUR algorithm in Wikipedia. Don't waste your time trying to take this to dispute resolution. There are other algorithms that you may find to be comprehensible. I provided some. Look them up. C does not define integer division. In C if the result of division in an integer the fractional part is discarded. Senor Cuete (talk) 15:43, 30 September 2017 (UTC)

I have undone the replacement in September 2010 by MadeYourReadThis of algorithms from the Explanatory Supplement to the Astronomical Almanac (2nd ed) by algorithm by Tøndering for these reasons:

• Tøndering is not as reliable a source as the Explanatory Supplement.
• The description in the article says integer division is used exclusively, but Tøndering's use of the floor function indicates the use of real numbers.
• The floor function isn't available for use with integers in some strongly typed programming languages, such as C#.
• If we're going to use real numbers, we should provide algoritims that return a Julian day (which includes the time of day as a decimal fraction of the day from noon) rather than an awkward mix of integers and real numbers. Jc3s5h (talk) 18:42, 30 September 2017 (UTC)

Of course I'm not satisfied. I still maintain that we should not say that these algorithms do not work for negative JDN when we know that they do work if properly implemented. (I doubt that the Explanatory Supplement to the Astronomical Almanac says they won't work for negative JDN, but I can't check.) I disagree with using the slash / to mean integer division. It's confusing, and leads to incorrect results if done the wrong way. (There's nothing wrong with using real numbers and then Floor. Any decent programmer knows that he has to consider whether his number representation is good enough for what he's trying to do. Double precision is good enough, but anyway it's not our problem.) And we should get rid of the table of constants which confused even you. Please take this to Dispute resolution. Eric Kvaalen (talk) 10:28, 2 October 2017 (UTC)

If you have a problem with the article, you can start an request for comment. Jc3s5h (talk) 12:13, 2 October 2017 (UTC)

I gave examples above, and gave page numbers in Richard's book showing the algorithms for converting JDN to calendar date do not work for JDNs significantly less than zero.

For the Gregorian calendar date to JDN algorithm Doggett states on page 604 "These algorithms by Fliegel and Van Flandern (1968) are valid for all Gregorian calendar dates corresponding to JD >= 0, i.e., dates after −4713 November 23". I wrote a C# program and compared the results for nodatime (which works for hundreds of thousands of years before or after AD 1). Counting down from JDN 0, I found the first failure for February 29, −4800, Gregorian calendar.

For the Julian calenar date to JDN algorithm Doggett states on page 606 "These algorithms are valid for all values of Y >= −4712, i.e., for all dates with JD >= 0." Using the above-mentioned C# program the first failure I found while counting down was for February 28, −5001, Julian calendar. You can evaluate those dates yourself in the algorithms and verify the errors. Jc3s5h (talk) 12:43, 2 October 2017 (UTC)

Well, they didn't work because you truncated toward zero instead of truncating toward minus infinity! That we have already established. I don't see why we have to give the algorithms in a way which is confusing and leads to wrong results. I don't know what you mean by "start a request for comment". Eric Kvaalen (talk) 15:26, 9 October 2017 (UTC)

I just put the algorithms into C# and let the language do integer division the way it always does. When testing an algorithm published in a reliable source, if there is a reasonable way to interpret the publication in a way that the algorithm fails (for certain values), then it fails. It must be evaluated with the worst interpretation, not the best.

I don't know of any up-to-date computer language that performs integer division by, in effect, taking the floor of the quotient. As far as I know they all truncate, by just ignoring the remainder. I have not explored the internals of the compilers, but I would expect that the fraction part of the result is never computed, because the compiler almost certainly uses the integer part of the central processing unit, and that hardware is only capable of computing the integer part of the quotient and the remainder.

As for requesting comments, see Wikipedia:Requests for comment. Jc3s5h (talk) 16:36, 9 October 2017 (UTC)

More detail: For recent Intel microprocessors, the integer signed division operation (IDIV) is described in volume 2A, page 3-442 of the Intel® 64 and IA-32 Architectures Software Developer’s Manual (a large file). The document states "Non-integral results are truncated (chopped) towards 0." Jc3s5h (talk) 17:06, 9 October 2017 (UTC)

Method of Meeus

double DateToJulianDayNumber(int month, double day, int year) //Meeus
{
int M, Y, A, B;
double JD;

if(month > 2){
    Y = year;
    M = month;
    }
else{
    Y = year - 1;
    M = month + 12;
    }
if((year > 1582) || ((year == 1582) && ((month == 10 && day >= 5.0) || (month > 10)))){ //Gregorian
    A = floor(Y / 100.0);
    B = 2 - A + floor(A / 4.0);
    }
else
    B = 0;
JD = floor(365.25 * (Y + 4716)) + floor(30.6001 * (M + 1)) + day + B - 1524.5;
return JD;
}

Senor Cuete (talk) 18:58, 22 November 2017 (UTC)

There are two problems with Meeus (specifically, the calculation of the JD from the calendar date as shown on page 60–63 the date from the JD of Astronomical Algorithms (2nd ed., 1998, with corrections as of August 10, 2019, Richmond: Willmann-Bell). First, it says right on page 60 "The following method is valid for positive as well as negative years, but not for negative Julian Day numbers." It's original research to claim it works for negative JDs.

The second problem is that the algorithm rigidly considers the last day of the Julian calendar to be 4 October 1582 and the first day of the Gregorian calendar to be 15 October 1582. But readers of this article may encounter many situations where the Julian calendar was used after 4 October 1582, or the Gregorian calendar used before 15 October 1582, so this choice is not convenient. Jc3s5h (talk) 19:04, 22 November 2017 (UTC) Revised; I was confused that this thread started off with JD to calendar date but then switched to a discussion of calendar to JD. 22 Nov 2017 22:18 UT

The given C program, when the 3rd line is fixed, and the JD is set to -584388, gives the Julian calendar date as 14.5 January -6311, when it should be 13 January -6311.

For an easier to verify Julian calendar date in the same neighborhood, consider noon 1 January -6312, which is exactly 1600 Julian years before JD 0 (noon 1 January -4712. Therefore its JD is 365.25 * (-1600), or -584,400. When -584,400 is input to the C algorithm, the result is 2.5 January -6311. Jc3s5h (talk) 23:01, 22 November 2017 (UTC)

You are right. I was using a different test to see if Meeus could be modified to use negative JDs by using some (int)floor()s. It worked for my test but not yours. I think I've got it but as you note, this is too far from Meeus - now it's WP:OR. I'll have a look at exactly what Meeus says about this. Senor Cuete (talk) 17:18, 23 November 2017 (UTC)

I checked the JDto date algorithm in Meeus. Meeus makes it clear that one should floor the results of the arithmetic expressions to get the integer part. This is the floor() operation in C. This was accomplished in the algorithm I had by using unsigned integers (type coercion). I tested it thoroughly in my IDE and using signed integers and the float operator where Meeus does, the algorithm does work with negative JDs. I realize that you probably won't use it in the article but I edited it to reflect exactly what's in Meeus so you can look at if you want. Senor Cuete (talk) 16:26, 24 November 2017 (UTC)

I assumed that the algorithms that I had were from Meeus but it looks like they could have been adapted from from Peter Duffet-Smith. Senor Cuete (talk) 17:19, 24 November 2017 (UTC)

I also edited the date to JD algorithm to reflect what it says in Meeus. Senor Cuete (talk) 17:25, 24 November 2017 (UTC)

Request For Comment on presentation of algorithms

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Should algorithms for converting between Julian Day and calendar date be written in a way that may be misinterpreted or which may lead to wrong results? (See discussion in Section #Reversion.) Basic'ly we agree that a couple of algorithms will work correctly if one "rounds" certain quotients toward minus infinity whether they are positive or negative, but the person whom we cite for the algorithms didn't say that, so the other editor wants us to say that the algorithms are only good for positive Julian Day. We also disagree about whether to write one of the algorithms in a simple way, or using a table of constants instead. Eric Kvaalen (talk) 07:25, 1 November 2017 (UTC)

"Should algorithms for converting between Julian Day and calendar date be written in a way that may be misinterpreted or which may lead to wrong results?" Yes, They should be described clearly. "WE" don't agree. Your original research indicates this but WP:OR forbids the inclusion of this in the article. What you describe is not rounding. The use of reliable sources is mandatory. It seems to me that you could state if the result of division is an integer, as I did in my description of the method of Baum. i.e. (integer)x = y/z. I think that this would eliminate the confusion that you experienced and wouldn't violate WP:OR. I strongly advocate a clear description of an algorithm rather than a table of constants. Maybe a note after the algorithm, that describes the fact that floor()ing the last results would make it work for JDs<0 would be acceptable. An example of a comprehensible algorithm can be found here: https://en.wikipedia.org/wiki/Mesoamerican_Long_Count_calendar#Calculating_a_western_calendar_date_from_a_Long_Count Senor Cuete (talk) 15:38, 1 November 2017 (UTC)

It is important that the algorithm come from a reliable source. If a reliable source presents the algorithm in a way that makes intuitive sense, rather than containing "magic numbers", that would be an improvement, but I don't know of such algorithms. I think the algorithms chosen should be either entirely integer, such that they could be implemented with integer assembly language instructions (no floating point instructions), or the algorithm should include time-of-day as a fraction. I see no reason to have an algorithm that rounds. Jc3s5h (talk) 19:05, 1 November 2017 (UTC)

User:Eric Kvaalen is not using the word "round" as it is understood in math. That's why he put it in quotes. When he describes it as rounding "certain quotients toward minus infinity whether they are positive or negative", he is talking about flooring the decimal results of division to the lower integer so that the algorithm will work for negative JDNs. This is the floor() function in C. Yes, this is a good idea BUT if a reliable source doesn't do it you would want to find a citation that says this, not a user's WP:OR. I think the pages of Peter Baum mention this and they are on-line. I think I linked to them in this page's discussion. This could be a citation to a reliable source. Another possibility would be to use the algorithm of Baum. It works for negative JDs. Senor Cuete (talk) 20:28, 1 November 2017 (UTC)

Actually, the word "round" can be used for rounding toward minus infinity -- see Rounding#Rounding to an integer. But no matter.

It seems to me that we three are in agreement that flooring will make the algorithm work for negative JD.

I was hoping that following JC's suggestion of starting a Request For Comment would bring in some other people, but so far nobody has come.

Eric Kvaalen (talk) 15:41, 2 November 2017 (UTC)

• Comment. I interpret the question as "Should Wikipedia provide a formula that always gives correct results, or one that is attributed to a reliable source but sometimes gives wrong results when applied by a user who hasn't read the small print?" As a user of Wikipedia I much prefer the former. Maproom (talk) 07:57, 10 November 2017 (UTC)
• Comment. I am unsure that I understand this; algorithmics, like maths, is largely a formal discipline. Much as a proof or derivation a priori is valid or not, irrespective of the source or who presents it, so is an algorithm. We might debate whether an algorithm is relevant to the article, or whether its attribution is correct and reliable etc, or whether it is comprehensibly presented and proved correct and effective, but if I present say, a sort or search algorithm, giving reasons for its merits and reliability, the question of who developed it is irrelevant to its acceptance or rejection, any more than if I claim in good context that 23456789 is a prime or that 154281241 is a square; doubting readers could check that for themselves even if Gauss and Erdős united in denying it. To cry OR in such cases makes no sense. Or suppose that someone claims that 15233563014311041 is prime and I check and point out that it is a square, my calculation, even if it cost me much labour, is irrelevant to the OR principle. At such levels maths and algorithmics are different from assertions based on opinions. If I state a conjecture, then OR might arise, but not a priori derivations or provable or obvious algorithms.
  As for ...whether to write one of the algorithms in a simple way, or use a table of constants instead, that is irrelevant, one uses either or both as long as they fit into the context of the article. If they are verifiable on inspection or on the basis of common knowledge (thirty days hath September etc) one does not need any particularly recondite "reliable sources".
  ... written in a way that may be misinterpreted or which may lead to wrong results? Definitely not! As in any other entry in any article, we do our best to weed out anything of the type, as has been shown possible in this very RFC. JonRichfield (talk) 08:13, 19 November 2017 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

LOP JD?

The "Variants" section of this article includes one named "LOP JD". According to the cited reference here, which is part of the explanatory notes for a software module, this variant was "chosen by our team at Laboratoire d'Oceanographie Physique, Museum National d'Histoire Naturelle, Paris." The National Museum of Natural History (France) does not have an oceanography (as opposed to marine biology) department, according to its website. On the French Wikipedia, "Laboratoire d'Océanographie du Muséum national d'histoire naturelle" (note the lack of "Physique") redirects to fr:Station de biologie marine de Dinard, which does not appear to have any connection with physical oceanography. There is a French organization called "Laboratoire d'Océanographie Physique et Spatiale" (website), affiliated with IFREMER, but they don't seem to have defined a variant of Julian dates. In view of the above, I would recommend deleting this entry from the table, as it does not appear to have a very reliable provenance. Tevildo (talk) 12:02, 16 June 2018 (UTC)

As there have been no comments, I've removed the item. Tevildo (talk) 19:25, 5 July 2018 (UTC)

Make 'Julian date' a disambiguation?

At present, Julian date redirects here. The term 'Julian date', although arguably incorrect, is not at all uncommonly used to mean dates in the form YYYY.DDD or DDD.YYY (or just DDD for perishable goods) – i.e., the Ordinal date. Julian calendar has just had to be protected because of an editor or editors trying to propagate an error made by a newspaper. So I wonder if we should preempt this by making Julian date a disambiguation? For each person trying to 'correct' an article, 100 will have walked away just confused. Comments? --John Maynard Friedman (talk) 21:45, 25 June 2019 (UTC)

Procedural note: pointers to this discussion added to some other talk pages by John Maynard Friedman point the "Julian day" article, rather than this talk page. Jc3s5h (talk) 23:41, 25 June 2019 (UTC)

Whoops, will fix. --John Maynard Friedman (talk) 10:03, 26 June 2019 (UTC)  Done --John Maynard Friedman (talk) 10:07, 26 June 2019 (UTC)

The confusion can occur with at least "Julian date", "Julian day", "Julian day number" (which redirects to "Julian day"), and "Julian calendar". We can't make them all disambiguation pages. The two non-redirects, "Julian day" and "Julian calendar" both have redirect, distinguish, or about templates at the top to try to point readers to what they might be interested. Maybe we shouldn't use templates and instead write a passage at the top of each article with clearer language than the standardized language of the template. And then ridicule anybody that tries to put the templates back. Jc3s5h (talk) 23:51, 25 June 2019 (UTC)

I was less concerned about over-enthusiastic "correctors" (who we can resolve in the usual way) than to help visitors confused by sloppy external usage and then can't work out which is what. (Compare "average": mean? mode? whaddyamean?) Our aim should be that they leave knowing what they wanted to understand and a bit more besides.

So yes, extended hat notes would do the job admirably, if that is permissible. --John Maynard Friedman (talk) 10:03, 26 June 2019 (UTC)

Chronological Julian date

I first added Chronological Julian date in the table (diff). Whereupon Jc3s5h reverted my edit with the comment “Added material does not agree with cited source because JD is always based on UT but source says CJD is based on local time zone.” I re-added the Chronological Julian date in the Variants section, this time under the table, where I noted the distinction between TT-based JD and local-based CJD. I don’t wish to wage wheel war; I believe that I adequately addressed Jc3s5h’s concern. If there are other reasons why Chronological Julian date should not be included in the Variants section, please let me know.

Actually, the issue of time scales applies to the rest of the table too.

• Ordinary (astronomical) Julian Day is reckoned in Terrestrial Time, unless otherwise indicated. Modified Julian Day as well.
• Truncated Julian Day Number, Lilian date, Rata Die, and any form of Julian Day with the word “Number” appended at the end (as in “X Julian Day Number”) are integer numbers for the whole day, without fractions.
• Unix Time and .NET DateTime ticks are in UTC, except for leap seconds where time stands still (or rather: the datatype value doesn’t change during that leap second) for 1 second = 10000000 ticks.

I know that the difference between TT and UTC is currently 37 + 32.184 seconds (as of 2019, since 2017) whereas the difference between local time and Universal Time can be several hours, depending on time zone (and whether Daylight Saving Time is in effect). But still… the formulas in the table don’t reflect this difference. — Adhemar (talk) 00:19, 17 August 2019 (UTC)

First, all the sites I can find that mention chronological Julian date seem to be personal websites. If this is to be included, I would want to see a definition from a source that meets the criteria found in WP:Verifiability and WP:Citing sources.

According to Explanatory Supplement to the Astronomical Almanac 3rd ed, p. 15, cited several times in the article,

The Julian date system may be used with TAI, TT, TCB, or UTC, so when the difference is significant, the particular timescale should be indicated.

Simply deeming the Julian date to always be associated with TT is not correct. Jc3s5h (talk) 01:28, 17 August 2019 (UTC)

CJD was removed years ago because it is not notable by WP standards. --Nike (talk) 02:57, 17 August 2019 (UTC) (JD 2458712.623)

So I encountered CJD yesterday; remembered vaguely that CJD was either JD + 0.5 or JD - 0.5 ignoring time zone and time scale issues (which means I encountered it before); went to this Wikipedia page to look up which; couldn’t find it; looked it up; and added it to this page as it was missing. Of course, today, I can’t remember for the life on me where I encountered CJD (yesterday or in the past). If the consensus is that CJD not notable or verifiable enough: I will be sad to see it go, but I won’t re-add it if someone deletes it.

On the IAU recommendation that JD be expressed in TT unless otherwise stated: that was already mentioned in the text, but I added the reference. The link points to the IERS website, since that HTML page is more accessible than the version I found on the IAU website, which is a scanned PDF where the text is not selectable. — Adhemar (talk) 08:47, 17 August 2019 (UTC)

I don't read the IAU recommendation as saying that "that JD be expressed in TT unless otherwise stated". It does recommend TT, and also acknowledges that sometimes other time scales are necessary, and specifically cites Seidelmann 1992, which is the 2nd edition of the publication I cited; I cited the 3rd edtion, which is considerably newer than the IAU resolution from 1997. The IAU resolution does not specifically say it's safe to assume TT unless otherwise stated. Jc3s5h (talk) 12:37, 17 August 2019 (UTC)

I surveyed the usage of "chronological Julian date" via Google and found the most detailed discussion by the inventor Peter Meyer on his website and on CALNDR-L. Less detail is in several forums, [1]. It is used by less than ten commercial software packages, [2], [3], SeaDataNet, Han Soft Date Time, Date::JD. I found it mentioned in only two reliable sources, a book and a journal paper. — Joe Kress (talk) 20:12, 19 August 2019 (UTC)