Talk:Julian day

Wrong formulas

The formulas given in the sections “Converting Gregorian calendar date to Julian Day Number” and “Converting Julian calendar date to Julian Day Number” appear to be wrong. For example, in the section “Converting Gregorian calendar date to Julian Day Number,” the value of JDN for Y = 1999, M = 3, and D = 23 is approximately 2,451,263.202. The correct Julian day number is 2,451,261. The formulas return non-integer values. The correct formulas must return integer values. —Jencie Nasino (talk) 05:46, 25 September 2019 (UTC)

I haven't looked at the formula in the article for a long time but the following can be used to confirm the JDN, and to do the reverse calculation.

• {{extract|1999-03-23|show=juliandate}} → 2451261
• {{extract|juliandate|2451261}} → 23 March 1999

Module:Date does the calculations. In that module, I used the formula from http://www.tondering.dk/claus/cal/julperiod.php#formula after extensively checking that it works well, assuming proleptic calendars. A julian date can be fractional on the assumption that the fraction corresponds to a partial day. If midnight is used as the start of a day, 12 noon would be 0.5 as a fraction of a day. Johnuniq (talk) 08:12, 25 September 2019 (UTC)

Did you read the part in Julian day#Julian day number calculation about all formulas using integer division? Jc3s5h (talk) 21:19, 25 September 2019 (UTC)

I tried the calendar->date formula making sure to use integer division, and it seems to be off by a couple days. For example, for today (10 October 2019), the formula given comes out as 2458768, when by all accounts it should be 2458766. For the example date you gave (23 March 1999), I get 2451263. I'd love to double-check the formula to see if it was mistyped, but I can't find an online copy of the book that's cited. Note that even if you forget to do integer division, the given value is still off by over a day.

Even accounting for the possibility that the month and/or day might start from 0 instead of 1 doesn't give the correct answer. I thought I had gotten something wrong in copying the formula over, but it appears it's not just me having issue with the formula. ShimmerFairy (talk) 06:14, 10 October 2019 (UTC)

These formulas, as given in the article, have been checked several times by other editors, including me. Now it's your turn to do some work. Please provide a detailed worked example that gives the wrong answer. Jc3s5h (talk) 11:56, 10 October 2019 (UTC)

Oh by the way, it is conventional when using dates such as your "10 October 2019" for days that do not start at midnight to do the conversion at noon. The Multi-Year Interactive Computer Almanac created by the United States Naval Observatory provides this relevant output:

                            CALENDAR                            
     
   Date        Time       Day      Julian Date      Day-of-Year
         (UT1)                        (UT1)            (UT1)
          d  h  m   s                    d              d
2019 Oct 10 12:00:00.0    Thu     2458767.000000     283.500000

Jc3s5h (talk) 12:06, 10 October 2019 (UTC)

First of all, I was actually working with the date 9 October 2019, so the result I was expecting was the correct one, I just made a typo in my message. Secondly, while trying to produce a working out, I realized that the integer division operator in the language I was using to test the algorithm floors instead of truncates, which just so happens to mess up when the result of division is negative (the "month - 14" numerators specifically are where this problem lies). Compensating for that does indeed give the right answer. ShimmerFairy (talk) 14:50, 10 October 2019 (UTC)

21/6/2010 the formula gives about 1 day more than it should. the problem is that the algorithm is for integer number mathematics and it gives wrong answers when used with real number mathematics.

>http://mathforum.org/library/drmath/view/51907.html</ref>46.132.4.67 (talk) 00

22, 31 December 2019 (UTC)

I have added the rounding rule used by those formulas in the article to make things clear.82.123.105.164 (talk) 02:23, 5 February 2020 (UTC)

@Jencie Nasino, Johnuniq, Jc3s5h, and ShimmerFairy: We had a big argument about the algorithm for going from Julian Day Number to dates almost three years ago (Talk:Julian day/Archive 4, sections 2, 3, and 4). I said that the way the algorithm is presented is very confusing (using a table of parameters) and that the algorithm works just fine for negative JDN so long as "div" is defined the right way. We couldn't come to an agreement so the article stayed the way it was, unfortunately.

According to Division (mathematics), the definition of "integer division" with a negative result is language-dependent! So it's not good enough just to say "divisions are integer divisions"!

By the way, here is an explanation of how the algorithm works:

• f, in the case of the Julian date algorithm, is the number of days since March 1, 4717 BC (it's zero on that day). For the Gregorian algorithm, f is a number that increases by 1 every day except that three times every 400 years it goes up by 2 when JD goes up by 1, so that the rest of the algorithm should yield the Gregorian date instead of the Julian date. For the other variables, I will just give the interpretation for the Julian date.

• e is the number of quarter days since 6 PM on the 29th of February, 4717 BC.

• g represents how far into the year we are, in days, past March 1.

• h is simply 2 more than 5 times g.

• D, the day of the month, comes from taking h mod 153 and dividing by 5, in other words time is cut up into "months" of 30.6 days. This works because the year starting in March is made of of sequences of five months of lengths 31, 30, 31, 30, 31.

• M, the month, is derived in the same way but using integer division instead of mod.

• Y, the year, comes from e divided by the number of quarter days in 365.25 days, with an adjustment to add 1 when the date is in January or February.

We could add the fact that mod(JDN+1,7)+1 gives the day of the week (Sunday being 1).

Eric Kvaalen (talk) 17:06, 17 June 2020 (UTC)

I will rigorously enforce WP:V and will not hesitate to seek administrator intervention. Jc3s5h (talk) 17:27, 17 June 2020 (UTC)

What are you talking about? Verifiability of what? (Please ping me.) Eric Kvaalen (talk) 19:37, 17 June 2020 (UTC)

The need for verifiability was discussed in the RfC which you started and which failed to gain consensus.

More specifically, on talk page, you did not cite any source for the explanations of the parameters which you listed.

As for your claim that mod(JDN+1,7)+1 gives the day of the week (Sunday being 1), as explained in our article "Modulo operation" the results vary among various computer languages if JDN+1 is negative; in some languages the result is implementation defined. And while "Modulo operation" is not a reliable source, it does cite some reliable sources (it could use some more). Jc3s5h (talk) 20:49, 17 June 2020 (UTC)

@Jc3s5h: You didn't ping me.

I am not proposing putting the above explanation of the algorithm into the article. That was just for the benefit of the people who read this talk page.

Do you agree that mod(mod(JDN,7)+8,7)+1 gives the day of the week?

And what do you say about the fact that the definition of "integer division" is language-dependent?

Eric Kvaalen (talk) 12:18, 18 June 2020 (UTC)

@Eric Kvaalen: My quick test in Excel indicates that =MOD(B12+1,7)+1 gives the day of the week, if cell B12 contains the JDN and the JDN is positive, 0, or a small negative number. I haven't tested for large magnitude negative numbers.

I believe the modulo function behaves differently in various languages and if I worked at it, I could find a language where the equivalent formula gives an incorrect result for negative JDN.

I have reliable sources that have this, or a similar formula, valid for positive JDN. I'll look when I get a chance.

As for integer division being implementation dependent for negative integers, I didn't say that, and I don't recall ever reading that. I'm saying the modulo operation is implementation dependent for negative numbers. Jc3s5h (talk) 12:51, 18 June 2020 (UTC)

@Jc3s5h: I will address the question of weekday below your new section header. As for the question of integer division, I didn't say that you said it's implementation dependent, I said that Division (mathematics) says that. So when we put, in the article, "(M − 14)/12" or "(M − 9)/7", the result is not well defined. Those two expressions are simply meant to distinguish January and February from the other months. They are supposed to give −1 for January and February and 0 for the other months, but in some computer languages they may give −2 and −1. It would be better, in my opinion, to simply define some variable, say C for "correction", as −1 if M is 1 or 2 and 0 otherwise, and then use this variable in the places where those expressions are used. And if, as I tried to convince you three years ago, we were to define integer division as floor(a/n), then the formulas could be used for dates which give negative JDN. But I know you won't accept that. Eric Kvaalen (talk) 06:43, 21 June 2020 (UTC)

@Jc3s5h: You didn't respond to this. By the way, I should have said that in some computer languages (M − 14)/12" or "(M − 9)/7" may give −2 for January, −1 for February and several subsequent months, and with "(M − 9)/7", 0 for September through December! I think we should give the formulas as:

For Gregorian dates: JDN=FLOOR(1461*(Y+4800+C)/4)+FLOOR(367*(M-2-12*C)/12)-FLOOR((3*FLOOR((Y+4900+C)/100))/4)+D-32075

For Julian calendar dates: JDN== 367 * Y -FLOOR(7 * (Y + 5001 + C)/4) +FLOOR (275 * M/9) + D +1729777

with C defined as I wrote above. That way it's unambiguous, and it would solve the problem of people using the formulas without realizing that the have to use "integer division" (of the right kind!). Eric Kvaalen (talk) 12:51, 21 June 2020 (UTC)

@Eric Kvaalen: The proposed formula is not in accord with the verifiability policy and will be difficult for editors unskilled in calendrical calculations to reconstruct after vandalism occurs. Jc3s5h (talk) 13:04, 21 June 2020 (UTC)

@Jc3s5h: I don't understand. Do you mean you don't know whether what I propose is the same as what we have (when that is interpreted the way you want)? We don't need to find a book for every little obvious thing, such as using FLOOR(A / N) instead of A / N (with integer division defined the way you want). If vandalism occurs, you just revert! Eric Kvaalen (talk) 13:37, 21 June 2020 (UTC)

@Eric Kvaalen:We are dealing with math and/or computer programming, where a single exception is sufficient to falsify any statement. I will interpret your proposal accordingly.

In the C# language, the input parameter of the Math.Floor method are of type Double or Decimal, therefore, we are dealing with floating point numbers. But the algorithm presently in the article only deals with integers.

In addition to my demand for reliable sources for "every little thing", I object to the whole concept of using floating point numbers while computing JDN. JDN is an integer, and should be done with integer calculations. If we are going to do floating point calculations, we should find an algorithm in a reliable source which accepts both the date and the time of day as input and calculates the Julian day, including the fraction part. Jc3s5h (talk) 13:51, 21 June 2020 (UTC)

Lest there be any misapprehension, Jc3s5h's expectations are entirely in line with WP:V policy, it is not a personal hobbyhorse if anyone thinks it is. But to express the question more broadly, why are we trying to do this anyway? Per WP:NOTGUIDE and WP:NOTMANUAL, we should not do more than say that these N authorative books give a calculation method and this usually reliable web page will give the JDN for any date and vice versa. That should be the end of it. --John Maynard Friedman (talk) 14:05, 21 June 2020 (UTC)

Regrettably, I am not aware of a "usually reliable web page" (if we interpret "usually reliable" in line with WP:IRS) that gives the information in a clear form that will satisfy the vast majority of users.

One web source I used to use was the US Naval Observatory, but the relevant page has been down for maintainence for several months, and the latest estimate for a return to service is summer 2020. Even when it worked, it always assumed any date before 15 October 1582 was Julian, and every date on or after 15 October 1582 was Gregorian. This doesn't work so well for, example, England. Also, I've been told the page was not available outside the US, and I seem to recall it was taken down during government shutdowns (where the Congress and president couldn't agree on a budget).

The website I usually use, which I have checked to my own satisfaction, is https://www.fourmilab.ch/documents/calendar/ but this site does not appear to satisfy WP:IRS. Also, it has a weird year numbering convention: for the Julian calendar, the years near the beginning of the Anno Domini era are numbered, -2, -1, 1, 2. But the years for the Gregorian calendar near the same time are numbered -2, -1, 0, 1, 2.

An additional consideration is that one place one might wish to convert dates is a library, while one is reading books and journals that are not eligible to be checked out. If it's a university library, but one is not affiliated with the university, one may not have wifi access. Inside a large building, cell phone connections to the internet may not work. So one may wish to have a program that resides on one's device to do the calculation when internet access is not possible.

Jc3s5h (talk)

@Jc3s5h: But surely that dives you straight into WP:OR. How is it the job of Wikipedia to develop and provide that algorithm? --John Maynard Friedman (talk) 16:07, 21 June 2020 (UTC)

@Jc3s5h and John Maynard Friedman: Yes, I agree that it's good to give a formula that people can use. I for instance made myself a little spreadsheet which I can use without having to remember where I last saw a URL for a site that does these calculations! But it wasn't easy to convert the formulas in this article to the correct form for a spreadsheet formula! I made a couple mistakes along the way.

It's true that if one divides a huge integer (like more than 15 digits) by another integer and then does FLOOR, one might not get the right answer. But that's not really worth worrying about. Nobody's going to do that in this context.

I still say the formulas we give are not good, because how many people will understand that every place where there's a division sign you have to round towards zero? I wouldn't know that. Eric Kvaalen (talk) 15:41, 21 June 2020 (UTC)

Then why are we trying to give them? This is using Wikipedia to publish your thesis! Again, that dives you straight into WP:OR. How is it the job of Wikipedia to develop and provide that algorithm? --John Maynard Friedman (talk) 16:07, 21 June 2020 (UTC)

It's not original research to give an algorithm that's provided in a reliable source. So we may be providing the algorithm, but we're not developing it. And a reason for giving it is so those readers who are able to can implement it on their own device, so they can use it when the internet is not available. But of course, they could just view the reliable source themselves, if they can afford it. Jc3s5h (talk) 20:22, 21 June 2020 (UTC)

Fair enough. I gained the impression that the accuracy or (verbal) precision of the source was being questioned and an improved (= OR) algorithm was being proposed in its place. So if you (pl) are just copying the source [which is out of copyright, I presume], how can this debate arise? --John Maynard Friedman (talk) 22:02, 21 June 2020 (UTC)

The issue is that the algorithms currently in the article are only asserted in the source to work for Julian day numbers greater than or equal to 0; my own experiments have found that they do indeed fail for negative JDNs that are many years earlier than 4718 BC. Eric Kvaalen would like to introduce original modifications to make them work earlier in the past.

As far as copyright is concerned, from what I've seen, there is seldom any hesitation to copy a few equations or formulas from one work to another, under the doctrine of fair use. The fact that there are relatively few ways to express the algorithm without introducing errors or creating great inconvenience for readers is a factor. Also, the algorithm in Doggett was taken from Fliegel and Van Flandern (1968)"A Machine Algorithm for Processing Calendar Dates" Communications of the Association of Computing Machines 11, 657. (I don't know how closely it was coppied; I don't have that article.)

It's also likely that Doggett's chapter is not covered by copyright, since he was a staff astronomer at the US Naval Observatory at that time. Works made in the course of their duties by employees of the federal goverment are not eligible for copyright. The copyright page of the book states "reproduction or translation of any part of this work beyond that permitted by Section 107 or 108 of the 1976 United States Copyright Act without the permission of the copyright owner is unlawful." [Emphasis added]. It's quite unusual for copyright pages to mention section 108, which is the section that allows copying of publications of federal employees. Jc3s5h (talk) 22:59, 21 June 2020 (UTC)

Upon further searching, I found a letter to the editor of the Communications of the ACM which contains a FORTRAN version of the algorithm. Jc3s5h (talk) 23:07, 21 June 2020 (UTC)

Excellent research, I'm impressed. Yes, clearly the copyright is ok.

I guess the "rewrite in your own words without close paraphasing" applies to FORTRAN code as it does to conventional text! I'm happy now that we have a reasonable justification for the current content. Like you, though, I can't see how it is possible to justify new code that goes beyond that supported by the source: that would certainly be OR. Obviously if Eric can find an RS that supports what he wants to add, the objection falls. --John Maynard Friedman (talk) 00:02, 22 June 2020 (UTC)

@John Maynard Friedman: You don't understand. All I'm saying is that we can rewrite the formulas to use FLOOR instead of so-called "integer division" which is not well defined and not commonly understood. Doing so would have the added benefit of allowing people to use the formulas easily. You can't do "integer division" in a spreadsheet for example, or with a calculator. I also think it's stupid to put in those caveats about the formulas only working for positive JDN when we know the formulas work for negative JDN (if written using FLOOR). We don't have to say that they work for all JDNs (if we don't have a "reliable source" to back it up!), but we're not obliged to put every statement which is in the source into our article! Eric Kvaalen (talk) 10:58, 22 June 2020 (UTC)

Is integer division well defined?

Is integer division well defined in mathematics, and in computer programming languages?

Many of the algorithms in the article use the integer division operation (but no use is made of the remainder, which might be thought of in math as one of the results of a division, the other result being the quotient). But Eric Kvaalen states in the thread #Wrong formulas ' All I'm saying is that we can rewrite the formulas to use FLOOR instead of so-called "integer division" which is not well defined and not commonly understood.' Jc3s5h (talk) 15:10, 22 June 2020 (UTC)

Discussion of integer division RFC

My understanding of division, based on my training in elementary school, formal university classes in FORTRAN, use of FORTRAN as an electronics engineer at IBM, and working on the CPU hardware of IBM System/390, corresponds with the following material from a FORTRAN programming manual near the time that Fleigel and Van Flanderen wrote their letter to the editor to Communications of the Association for Computing Machines (which I will add to the article as further reading shortly). The source is IBM System/360 and System/370 FORTRAN IV Language, IBM publication number GC28-6515-10, May 1974, page 29.

6.

When division is performed using two integers, any remainder is truncated (without rounding) and an integer answer is given. The sign is determined normally.

Examples:

I	J	I/J
9	2	4
−5	2	−2
1	-4	0

I think the results in the table agree with how mathematicians define the quotient in cases where the remainder is given separately; does anyone believe otherwise? Does anyone know a programming language that gives different results? Jc3s5h (talk) 15:10, 22 June 2020 (UTC)

• Paging David Eppstein. EEng 16:45, 22 June 2020 (UTC)

I found a case where an operator that might be used as integer division, but really is not, is "floor division". In the current Python language reference it is indicated that the floor division operator, "//", first performs a floating point division with the two operands and then performs a floor function.

The current Python math.floor function, math.floor(x), returns "the largest integer less than or equal to x." This gives different results for the quotient than FORTRAN division of integers. Jc3s5h (talk) 16:52, 22 June 2020 (UTC)

In mathematics, for the division of an arbitrary integer x by a positive integer y, the quotient is always q=floor(x/y) so that the remainder x-qy lies in the range [0,y-1]. Python integer division is the same as the mathematical convention. Many other programming languages, though, including C, C++, and Java, differ from the mathematical convention by always rounding x/y towards zero, so that when x is negative the remainder will also be negative. I don't know whether there is a standard mathematical convention for quotient and remainder when the divisor y is negative or which programming languages follow it. — Preceding unsigned comment added by David Eppstein (talk • contribs) 17:16, 22 June 2020 (UTC)

In Pascal, the / operator may be used on integer or real operands, and always yields a real result. This language also provides the DIV and MOD operators, both of which may only be used on integer operands and yield integer results. So 22 DIV 7 returns 3; and 22 MOD 7 returns 1. Regarding negative operands: this isn't a FLOOR case, it rounds towards zero. To quote BS 6192, section 6.7.2.2:

A term of the form i div j shall be an error if j is zero, otherwise the value of i div j shall be such that
  abs(i) - abs(j) < abs((i div j) * j) ≤ abs(i)
where the value shall be zero if abs(i) < abs(j), otherwise the sign of the value shall be positive if i and j have the same sign and negative if i and j have different signs.

A term of the form i mod j shall be an error if j is zero or negative, otherwise the value of i mod j shall be that value of (i-(k*j)) for integral k such that
  0 ≤ i mod j < j.

--Redrose64 🌹 (talk) 21:38, 22 June 2020 (UTC)

I think that what David Epstein has said supports my contention that integer division is not well defined (Python defines it differently from C). But more to the point is that people don't know how it is defined! (Do any of you know which way to round, in FORTRAN say, if both the dividend and the divisor are negative??) That's why I don't like the way we present the formulas in our article. As one can see by looking over past comments on this talk page and its archives, it's a cause of confusion.

In our formulas, we have the expressions "(M − 14)/12" and "(M − 9)/7", where the rounding has to be done toward zero, because it's simply meant to distinguish January and February from the other months. They are supposed to give −1 for January and February and 0 for the other months, but in Python they would give −2 for January, −1 for February and several subsequent months, and with "(M − 9)/7", 0 for September through December!

In the other places where integer division is used in our formulas, the formulae work so long as the dividend is positive, but if the dividend is negative and you use the kind of integer division used in C or FORTRAN then our formulae don't work!

Eric Kvaalen (talk) 10:20, 23 June 2020 (UTC)

I'd like to make David Eppstein's post more concrete by applying it to the examples from the IBM FORTRAN manual above:

I	J	I/J	q = floor(I/J)	remainder = I-qJ
9	2	4	4	1
−5	2	−2	−3	1
1	-4	0	−1	−3

This leads to some surprising notation issues. If we write the results of the first row as a mixed number it would be 4+1⁄2. The implied positive sign before the 4 also applies to the fraction 1⁄2.

If we look at the second row, we would write it as −2+1⁄2. So, unlike what we are used to when J and K are both positive, the quotient (−3) when expressed as quotient and remainder is not equal to the integer part of the mixed-number representation. Also, the remainder (+1) is not equal to the denominator (−1) of the mixed-number representation. Jc3s5h (talk) 13:57, 23 June 2020 (UTC)

As stated elsewhere on Wikipedia (Division (mathematics)#Of integers and Modulo operation) there is no specific definition of integer division for negative divisors or dividends and conventions vary between programming languages. I note that an IP editor in February already specified the exact use of integer division in the formulae in the article, and the formula given by Fliegel and Van Flandern has been written specifically for round-to-zero (truncation) division (in particular, under truncation division, the addition of + 4800 is required for the formula to work for years back to -4713; conversely, as stated above the (M - 14)/12 fails for floor division). Personally, I'd prefer if we found a source that explicitly uses floor/trunc within the formulae. Arcorann (talk) 01:08, 29 June 2020 (UTC)

• Comment: This is a bit of a strange RfC that seems more focused on the second part of the question (in computer programming languages) than the first (in mathematics). I'll only focus on the first part of the question. Basically, the question itself isn't very well-defined. But division on the integers is well-defined in some way that intuitively makes sense.
  In mathematics, asking if something is define-able isn't a very meaningful question (outside of topics in logic, set theory, etc. that we're clearly not talking about). Division is not well-defined as a group operation for the integers or even as a binary operation on the integers, but then again nor is division well-defined in that way for the real numbers (due to division by zero).
  However, division on the integers is well-defined in other ways. For instance, take the binary operation of division on the nonzero rationals $\,f\colon \mathbb {Q} ^{\times }\times \mathbb {Q} ^{\times }\rightarrow \mathbb {Q} ^{\times }$ that sends $\left({\frac {a}{b}},{\frac {c}{d}}\right)$ to ${\frac {ad}{bc}}$. Then the intersection of the Cartesian square of the nonzero integers $\mathbb {Z} ^{\times }$ and the pre-image of the nonzero integers gives a well-defined function $\,g\colon (\mathbb {Z} ^{\times }\times \mathbb {Z} ^{\times })\cap f^{-1}(\mathbb {Z} ^{\times })\rightarrow \mathbb {\mathbb {Z} } ^{\times }$. This function $g$ sends pairs of nonzero integers $(a,b)$ (but only the ones such that ${\frac {a}{b}}$ is an integer) to the nonzero integer ${\frac {a}{b}}$. You could also define integer division as a function $\,h\colon (\mathbb {Z} ^{\times }\times \mathbb {Z} ^{\times })\rightarrow \mathbb {\mathbb {Q} } ^{\times }$ as just sending the integers $(a,b)$ to the rational number ${\frac {a}{b}}$. You could also define it using Euclidean division (basically David Eppstein's answer above, and it actually works for negative divisors as well). There are plenty of ways to have a well-defined integer division.
  This probably only answers the literal question Is integer division well defined in mathematics but not the underlying content dispute. If this is about whether to use the floor function or not in the presentation of algorithms, then it's clarifying to use the floor function instead of straight division (even if your chosen programming language interprets a/b for integers to mean the floor function). — MarkH₂₁^talk 10:29, 21 July 2020 (UTC)

Rata Die calendar

The table claims that day one of "Rata Die" is 1 January 1 AD, proleptic Gregorian calendar. I believe this is incorrect. Rather than Gregorian, I believe it's proleptic Julian. Alexgenaud (talk) 16:55, 2 February 2021 (UTC)

Dershowitz and Reingold state in Calendrical Calculations (3rd ed., p. 10)

We have chosen midnight at the onset of Monday, January 1, 1 (Gregorian) as our fixed date 1, which we abbreviate as R.D.

They provide a footnote indicating that R.D. stands for Rata Die. Jc3s5h (talk) 17:04, 2 February 2021 (UTC)

Julian Date Number ZERO

Algorithm under Converting Gregorian calendar date to Julian Day Number gives me JDN 0 to be Nov 24, 4713 BC. But text says it should be Nov 24, 4714 BC. Day and month ok, but year wrong.

Also, algorithm under Julian or Gregorian calendar from Julian day number gives me Gregorian date Nov 24, 4712 BC as JDN 0.

But for more recent dates it's ok.

It's just me?

- Nerun (talk) 22:42, 13 February 2021 (UTC)

The years produced by the algorithm are negative, zero, or positive. In stating your result as "Nov 24, 4713 BC" you have changed from signed notation, also known as astronomical year numbering, to BC/AD notation. Perhaps you made this change incorrectly; 4714 BC is the same as −4713. Jc3s5h (talk) 23:47, 13 February 2021 (UTC)

Thank you. But why i get:

Aug 30, 2132 AC when i convert from NDJ 2,499,998

Sep 1, 2132 AC when i convert from NDJ 2,499,999

Sep 2, 2132 AC when i convert from NDJ 2,500,000

Sep 3, 2132 AC when i convert from NDJ 2,500,001

Where is 31st Aug?

Something wrong with my Python code maybe? Gist Here

Well, it's surely my code...

Nerun (talk) 20:44, 14 February 2021 (UTC)

I looked at your code. The first thing I noticed is it's Python. Then I saw this assignment:

Ju = int((1461 * (Y + 4800 + (M - 14)/12))/4 +(367 * (M - 2 - (12 * ((M - 14)/12))))/12 - (3 * ((Y + 4900 + (M - 14)/12)/100))/4 + D - 32075)

First, the algorithm uses integer division. Each and every division must be an integer division. It isn't correct to do floating point divisions and then turn the result into an integer at the end.

Second, Python has a floor division operator, "//". But read the footnote 68 in the article. With FORTRAN division, as was used in the source this algorithm came from originally, the remainder of a division has the same sign as the dividend, and the remainder may be positive or negative. In Python, the remainder is always 0 or positive, so the quotient is sometimes different from FORTRAN. You will need to find a way of doing division in Python that gives the same result as a FORTRAN division. Jc3s5h (talk) 21:37, 14 February 2021 (UTC)

I love you. Thank you very much. That's all for me.

Research: math.fmod() for Python gives negative or positive remainders!

- Nerun (talk) 02:02, 15 February 2021 (UTC)

Irrelevant date/time scales

The table of time scales under Variants includes some which, while interesting, are completely unrelated to Julian day (the subject of this article) and should be removed. In particular, Mars Sol Date, Unix time, and .NET DateTime are not even counts of (Earth) days, which is fundamental to the concept of JD. Include See also references to these other time scales if you like, but please do not pollute this table with them. Doug Ewell (talk) 21:37, 16 July 2021 (UTC)