Talk:Julian day/Archive 5

This is an archive of past discussions about Julian day. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

←

Archive 3

Archive 4

Archive 5

Switch to CE/BCE

Per WP:MOSDATES, choice of CE/BCE or BC/AD should be driven by content. In this case it's an astronomy topic with a minor in computing, use of CE/BCE dominates in the relevant professional communities. Even Jesuit astronmers are now following this convention, in papers I've read. Guy (Help!) 13:38, 30 August 2019 (UTC)

While I support this change, per MOS:ERA it is a controversial change that needs an RFC with supporting evidence. --John Maynard Friedman (talk) 14:03, 30 August 2019 (UTC)

Can you provide a reliable source that surveys the use of CE vs AD notation in astronomy and states the former is predominant? Even if you could, Julian dates are not used exclusively in astronomy; they are also used in computing (even when we ignore those who try to apply the name "Julian date" to the format yyyy-nnn). Jc3s5h (talk) 14:37, 30 August 2019 (UTC)

I'm not sure that it matters where and how it is used, what really matters is how the majority of reliable sources give the epoch. --John Maynard Friedman (talk) 15:42, 30 August 2019 (UTC)

The standard in astronomy is to use neither. Astronomy uses ± years, with + usually understood. — Joe Kress (talk) 17:53, 30 August 2019 (UTC)

The resolution of the IAU "On the use of Julian Dates" uses both BC and −, that is, 4713 BC and −4712. If our article were to adopt −0+ years, year 0 would appear within Scaliger's explanation of how he determined that the first year of Julian Period was 4713 BC, because he already knew the character of the solar and lunar cycles for 1 BC, year 0. — Joe Kress (talk) 21:12, 30 August 2019 (UTC)

I added year 0 to Scaliger's explanation, although he did not use year 0 himself. Nor did he use any abbreviation. BC and −0+ years could be swapped, or BC eliminated, depending on consensus. — Joe Kress (talk) 21:39, 30 August 2019 (UTC)

John Maynard Friedman wrote "I'm not sure that it matters where and how it is used, what really matters is how the majority of reliable sources give the epoch." I see no reason to give any special status to sources that explain the origin of Julian dates. Jc3s5h (talk) 22:59, 30 August 2019 (UTC)

@Jc3s5h:, I hadn't really thought in terms of its origins. What I had in mind are modern text-books of astronomy and computing, which explain to students what a Julian date is: I can't see how anyone could do that without also defining the epoch in terms a more familiar era. Exactly as this article does. Although we could dispense with the AD/CE/BC/BCE suffixes in almost all cases and just use a raw number as described by Joe Kress, we really do have to say in the lead that Julian day number 0 [is] assigned to the day starting at noon on Monday, January 1, 4713 BC (or 4713 BCE). We are forced to make a choice. --John Maynard Friedman (talk) 23:15, 30 August 2019 (UTC)

I suspect that virtually all of the references we already give in our article use BC/AD. But, our article does not use astronomical dating, which is year/month/day. There isn't even a template for that, {{use ymd dates}}. — Joe Kress (talk) 02:06, 31 August 2019 (UTC)

My impression is that "astronomical dating" is loosely defined; everyone in the field of astronomy agrees that one the year 2 BC would be written "-0" or "−0", but I don't think you would find a well-known astronomy standard that says the order of the date elements has to be year month day. Jc3s5h (talk) 18:47, 31 August 2019 (UTC)

The question is: do current sources reference a religious dating system? Answer, as far as I can tell: No0. Example: [1] Guy (Help!) 00:23, 1 September 2019 (UTC)

I didn't have any trouble finding some sources that use AD, BC, or both. [2] [3] [4] [5] I would add that changing the letters from AD/BC to CE/BCE doesn't really stop it from being a religious dating system. Jc3s5h (talk) 00:37, 1 September 2019 (UTC)

I don't have a strong general attachment to either AD/BC or CE/BCE, but since the Easter (Paschal) cycle played an important role in Scaliger's development of his Julian Period, there's a reasonable argument in favor of AD/BC notation in this article. --SteveMcCluskey (talk) 00:48, 1 September 2019 (UTC)

The astronomer, Herschel, is quoted in the article using BC. I generally prefer CE/BCE, but see no need to change it now. —Nike (talk) 21:55, 1 September 2019 (UTC) (JD 2458728.413)

Add weekday formula?

If a formula to compute the day of the week from the JDN is to be added, as suggested by Eric Kvaalen at the end of the above section, there should be a statement as to the range of validity of the formula.

According to our "Week" article, in the "Hellenistic and Roman era" section, the cycle of week days can be verified as far back as 6 February AD 60; this information is cite to

Nerone Caesare Augusto Cosso Lentuol Cossil fil. Cos. VIII idus Febr(u)arius dies solis, luna XIIIIX nun(dinae) Cumis, V (idus Februarias) nun(dinae) Pompeis.
Robert Hannah (2013). "Time in Written Spaces". In Peter Keegan; Gareth Sears; Ray Laurence (eds.). Written Space in the Latin West, 200 BC to AD 300. A&C Black. p. 89.

I do not posses either of these works. I wouldn't add information to an article unless I had read the source for the information myself. Jc3s5h (talk) 13:49, 18 June 2020 (UTC)

The MOD(a,n) function, in any computer language, returns a remainder r that satisfies

a=q\times n+r

for some integer q. In some languages, r may be negative in certain cases. So mod(JDN,7) may be negative for negative JDN, but it won't be less than −7. So if we then add 8, it will be positive. If we then do MOD again, we will always get an integer between 0 and 6, no matter what computer language we use. Adding 1 gives the number of the day of the week.

I don't understand what you mean by the "range of validity" of a formula for day of week. The day of the week goes from Sunday to Saturday every seven days, forever into the future and in all time past! There's no such thing as "verifying" that this was true in AD 60! Or do you mean that we have some record for that year saying that a certain day of the Julian calendar was a certain day of the week? Do you think that maybe people got confused at some point in time and lost track of which day of the week it was? It is well accepted that we can extrapolate back further than AD 60 in talking about days of the week. For example, there is a lot of discussion in the literature about the date of the crucifixion of Christ, and everybody accepts that we can say which day of the week any particular Julian date was.

Eric Kvaalen (talk) 06:43, 21 June 2020 (UTC)

Yes, I do mean that "maybe people got confused at some point in time and lost track of which day of the week it was?" If we make an unqualified statement "JD 0 = Noon on Monday, January 1, 4317 B.C.E. (Julian)" (Dershowitz & Reingold, p. 16) we would be wrong, because, as far as we can tell, the concept of a week hadn't even been invented at (or communicated by God to his people, as the case may be) at that point. But it Dershowitz & Reingold did it right; earlier in the chapter (p. 10) they stated, in relation to using AD with the year 1 (Gregorian) "Of course, this is anachronistic, because there was no year 1 on the Gregorian calendar—the Gregorian calendar was devised in the sixteenth century...." So read in this context, readers will understand that some of the information in the chapter is proleptic.

So if we provide a formula to convert JDN to day of week, we should be clear what the earliest date is that we have evidence that it agrees with actual use by people of the time, and warn readers that it is proleptic before that date.

Reingold, Edward; Dershowitz, Nachum (2008). Calendrical Calculations (3rd ed.). Cambridge University Press. ISBN 0-521-70238-0.

Jc3s5h (talk) 11:59, 21 June 2020 (UTC)

The source for the following formula and conditions is

Richards, E.G. (1998). Mapping Time: The Calendar and it's History. Oxford University Press. ISBN 978-0192862051.

Richards in chapter 23, "Mathematical Notes" states that when mod(A, B) is used, "we always assume that A and B are integers (A ≥ 0 & B ≥ 0)." (p. 292) Richards, in Chapter 22, "Calendrical Conversions", p. 291, mentions "Algorithms which use decimal numbers are best avoided when working with computers or calculators since they may not record with sufficient accuracy; for example, when the result of a calculation should be exactly 1, some computers might record it as 1.999...; if we ignore the decimal, we are wrongly left with 1 rather than 2. As a bonus, integer arithmetic is performed faster than decimal arithmetic in many computer systems." In chapter 24, "To Calculate the Day of the Week" on page 309, Richards gives this formula for the calculation of the day of the week from the Julian day number (where Sunday is assigned the number 1):

W = 1 + mod(J+1,7)

It is not mentioned on this page, but of course the result of the formula applies the at moment of noon and several hours following noon. What happens to the name of the weekday later in the Julian day depends on context. Jc3s5h (talk) 13:28, 21 June 2020 (UTC)

@Jc3s5h: It's fine, because it says that J is the "Julian day number", not the "Julian night number". I think it is clear in our article that the Julian day number refers to a particular date, not to the period of time from 12h00 GMT of one day till 12h00 GMT of the next. And each date belongs to just one day of the week. By the way, shouldn't that quote say "when the result of a calculation should be exactly 2"? Eric Kvaalen (talk) 15:41, 21 June 2020 (UTC)

@Eric Kvaalen: No, a particular JDN refers to a period of time beginning at noon UT and ending at the next UT noon. A JDN is not a Gregorian date, a Julian date, a date in an Islamic calendar, or a date in any other calendar (but it can be expressed with times of day combined with dates from those other calendars). Jc3s5h (talk) 20:28, 21 June 2020 (UTC)

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)

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)

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. E Eng 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 ( http://en.wiki.x.io/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)

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)

Error in Page Loaded Time Demonstration

The page includes a little demo that shows the UTC time the user loaded the page along with a "refresh" link. It produces an erroneous result that's off by an hour and 20 minutes from the actual UTC time the page was loaded.

Phil 174.97.235.231 (talk) 05:48, 25 April 2023 (UTC)