Talk:Julian day

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)

If Wikipedians are allowed to use citation 68 in the article to supply the formula, why aren't they allowed to use that same citation where it explicitly says integer division rounds "toward zero"? Why does that require a citation 'f'? And why does rounding towards zero need explained in this article at all? Further, the paragraph preceding the math says all formulas below round toward zero, but then each formula's introduction *also says* integer division... and omits "towards zero". I corrected one before coming over to the talk page to mention these issues. I've never made a Wikipedia edit before. 65.31.58.24 (talk) 19:57, 17 August 2021 (UTC) I should've been clearer when I asked why is "towards zero" explained in this article. I was implying that "integer division towards zero" should link to another article ( https://en.wikipedia.org/wiki/Division_(mathematics)#Of_integers), rather than being described in this one. 65.31.58.24 (talk) 20:27, 17 August 2021 (UTC)

The chapter by Doggett does say that the variables are integers, but does not specify which programming language the formulas were originally written in. The problem is that different programming languages do integer division a little differently when negative numbers are concerned. Doggett states that the algorithms are from fliegel and Van Flandern. Footnote f provides additional information from an article by Fliegel and Van Flandern, which makes it clear that since the algorithms were originally written in FORTRAN, the FORTRAN method of doing integer division should be used. Jc3s5h (talk) 22:16, 17 August 2021 (UTC)

The chapter by Doggett does say that the variables are integers, and *also* does specify that "towards zero" is the correct rounding to use to make the algorithms work. I'm quoting "towards zero" because it explicitly appears in the citation. (I would understand the circuitous structure of this article if "towards zero" did not appear in an allowable citation.) I'll have to re-read the article at some point: my initial impression was that programming language was not relevant to the article (I doubt they had many programming languages to pick from back in the 1600's), but I may be incorrect in that impression. FYI, it seems that the article is now *even less* clear than before, claiming that negative values are "rounded up" rather than "rounded towards zero" or "rounded towards negative infinity".65.31.58.24 (talk) 22:51, 23 August 2021 (UTC)

As well as I know, Fortran has always, and still does, round toward zero. Note that it originated on the IBM 704, which uses sign-magnitude arithmetic. In the original C, it could go either way, as long as the % operator gave the appropriate remainder. Later on, it was standardized as the same way as Fortran. As far as I know, all computer hardware does it the Fortran way, since they have to support Fortran. Yes there are a large number of algorithms that need FLOOR. I learned Fortran first, and PL/I not so much later. PL/I has (and has always had) a FLOOR function. Otherwise, PL/I divide does it like Fortran. Gah4 (talk) 22:30, 20 October 2021 (UTC)

It's clear that whatever computer was used by Fliegel and Van Flandern, they used integer variables and Fortran. The computer did not round. It had registers with bits to store integers, including the dividend, divisor, quotient, and remainder. When the integer portion of the CPU was used, there simply wasn't any place to store a fraction. So there was no rounding, just computation of a quotient and remainder. The footnote in the article indicates that rounding toward zero is functionally equivalent to the way Fortran calculates a quotient and remainder, but the computer doesn't actually do any rounding.

The IBM 360, 370, 390, and z-series are famous for being backward compatible. The z/Architecture Principles of Operation 10th ed. (IBM; 2012) indicates beginning on page 7-207 that division with either signed or unsigned numbers is possible, using different assembly language instructions. Regarding how the remainder is calculated, IBM states

The sign of the quotient is determined by the rules of algebra, and the remainder has the same sign as the dividend, except that a zero quotient or a zero remainder is always positive.

I think it's reasonable to believe that whatever computers were used by Doggett, Fliegel, and Van Flandern were functionally equivalent to the IBM/360 family and the IBM Fortran compilers.

I think it would be best to keep in mind that in the hardware and software intended by Doggett, Fliegel, and Van Flandern, there is no rounding. The article only mentions rounding for the benefit of readers stuck with hand calculators, or software like Excel, that do not provide easy access to integer arithmetic. Jc3s5h (talk) 16:12, 21 October 2021 (UTC)

I call it rounding toward zero, but in any case, that is what most do now. I suspect it is that Fortran did it because IBM computers did it, and other companies do it because Fortran does. As for S/360 and successors, S/360 floating point divide also gives the truncated (round toward zero) quotient. Except that the 360/91 gives the rounded to nearest quotient, using a Newton-Raphson divide algorithm. Gah4 (talk) 03:15, 22 October 2021 (UTC)

I don't have any System/360 assembly language reference material at hand, but I don't understand why a floating point divide would yield an integer quotient rather than a floating point quotient. [This is not really related to the article, since the article only deals with integers. Just curious.]Jc3s5h (talk) 15:36, 22 October 2021 (UTC)

Yes floating point, but the rounded down quotient. As a decimal example, 2/3 would come out 0.666666 instead of 0.666667, with the latter being the rounded (to nearest) value. This might affect some of those who do integer calculations in floating point. Gah4 (talk) 19:31, 22 October 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)

Makes sense to me. WP:BEBOLD and remove them, see if anyone provides a convincing reason to reinstate. --John Maynard Friedman (talk) 22:42, 16 July 2021 (UTC)

OK, I agree about removing ones for Mars, but the others are related to JD in that they continuously increase. That is, they are scaled and offset from JD. This helps those converting to/from JD, using those systems, to get it right. Gah4 (talk) 22:36, 20 October 2021 (UTC)

I disagree that similar time scales like Unix time should be removed. Both MJD and Unix time are commonly used in logs, for instance, and it is therefore useful to know how to convert between the two. In fact before I took a look at this Talk page, my main use of this page was to figure out a) what MJD was, and once I knew that b) figure out how it relates to other time scales (Unix time in particular). Since Unix time is so ubiquitous, it seems reasonable to provide information relating the two time scales in this article. Akblakney (talk) 23:21, 27 December 2021 (UTC)

2460000

It’s Julian Day 2460000. It seems slightly notable. Only happens every 27 years. Any way to get this featured?

—-Nike (talk) 08:57, 24 February 2023 (UTC) (JD 2459999.87282)