Talk:Julian day/Archive 2

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Contradiction between Template:JULIANDAY and Julian day#Calculation

Thanks, I copied the discussion to Template_Talk:JULIANDAY#Contradiction because the error is in the template. --Erzbischof (talk) 09:10, 24 February 2009 (UTC)

.NET DateTime

Besides UNIX time, there are two time standards defined by Microsoft. The .NET DateTime structure is defined as follows: "Time values are measured in 100-nanosecond units called ticks, and a particular date is the number of ticks since 12:00 midnight, January 1, 0001 A.D. (C.E.) in the GregorianCalendar calendar. For example, a ticks value of 31241376000000000L represents the date, Friday, January 01, 0100 12:00:00 midnight. A DateTime value is always expressed in the context of an explicit or default calendar." This seems to have all the same naive difficulties as POSIX time, it is unclear what they are doing in detail -- that is, I have no idea how to convert .NET time to UTC or TT. DonPMitchell (talk) 03:26, 24 July 2009 (UTC)

Oct 5 1582 - bug in some JDN calculators

I believe the Julian Day Number of Oct 5, 1582 should be equal to 2299161, but I'm not sure. This is the same as Oct 15, when the switch from Julian to Gregorian calenders occured. My own test code marches a year/month/day count from 4713 BCE and compares a calculated JDN to a running day count. However, some JDN calculators (like isotropic.com) give a JDN of 2299151 for that date, and so does the JULIAN subroutine in the JPL ephemeris software. There is some subtle mistake one way or the other. Strangly, all these programs agree on the JDN of 0.0 and the JDN of modern dates, they just are off by 10 days in 1582. I wonder what the bug is? DonPMitchell (talk) 15:02, 26 July 2009 (UTC) (See reply below from Mottelg (talk) 12:16, 15 October 2009 (UTC).)

Let's go to the source. Herschel was the first person to use the Julian period as a count of days, rather than a count of years. In his book Outlines of Astronomy (available at books.google.com) he indicates the last day of the old style in Catholic nations (Oct. 4, 1582) was 2,229,160. The next day in Catholic nations, in the Gregorian calendar, was 2,229,161.

Can you give a citation to the JPL ephemeris software? --Jc3s5h (talk) 17:18, 26 July 2009 (UTC)

The JPL code is OK, I made a mistake there, but isotropic.com is bugged. I believe they must just have an off by one error on when they switch over from Julian to Gregorian. DonPMitchell (talk) 13:40, 29 July 2009 (UTC)

---

Reply to "bug" from Mottelg (talk) 12:16, 15 October 2009 (UTC): It's not a bug. It depends which calendar you are using. Your test code counting forward from 1/1/-4712, counts Julian calendar dates (proleptic until year -45). (Your code will have treated every fourth year as a leap year without exception). October 5, 1582, Julian = JDN 2299161. Oct 5, 1582, Gregorian was JDN 2299151. The 10 day difference was the difference in the 1500's between the Julian calendar and the Gregorian calendar (the latter, proleptic until Oct 5, 1582), i.e. in the year 1582, the Gregorian date, Oct 5, occurred 10 days earlier than Oct 5, Julian. Since then, that difference has grown by 1 day in each of the years 1700, 1800 and 1900 (i.e. in the last year of each century, except for 1600 and 2000, which were leap years in both calendars). Date m/d/y Julian now occurs 13 days after m/d/y Gregorian, so the JDN of m/d/y, Julian minus the JDN of m/d/y, Gregorian = 13 for the 20th and 21st centuries.

The general convention is that, unless otherwise specified, dates > Oct 4, 1582 are assumed to be Gregorian, dates < Oct 5, 1582 are assumed to be Julian. JDN 0 is 1/1/-4712, Julian proleptic = Nov 24 -4713 Gregorian proleptic. Note that at that time, the date m/d/y, Julian proleptic, occurred 38 days before m/d/y Gregorian proleptic. As you go backward from 1582, the difference of 10 days reduces by 3 days every 400 years. In the 200's the difference is zero, and before that, the difference (i.e. the JDN of m/d/y, Julian minus the JDN of m/d/y, Gregorian proleptic) is negative, its absolute value increasing the further back you go. Mottelg (talk).

---

Further comment from Gleyshon

Can we get a citation from a published source about that convention dates > Oct 4, 1582 are assumed to be Gregorian, dates < Oct 5, 1582 are assumed to be Julian? It threw me in the table for Alternatives on this page because in the Epoch column, the BC dates are Julian and the other dates are Gregorian. The title 'Julian Day' implied it might be related to Julian Calendar dates... at any rate the definition of Epoch to head the column ought to be made clear.

Gleyshon (talk) 22:33, 2 July 2011 (UTC)

No, historians are sloppy about this and no definitive statement that applies to all or most publications is possible. Jc3s5h (talk) 23:46, 2 July 2011 (UTC)

Invalid edit

This edit seems invalid; I can find noting wrong with either the Gregorian date algorithm or the Unix time algorithm. The Unix time algorithm does seem overly complex. --Jc3s5h (talk) 15:41, 8 September 2009 (UTC)

That was me, see below for a detailed query of the presented algorithms/formulas/whatever :). 82.132.139.213 (talk) 10:25, 9 September 2009 (UTC)

Gregorian to Julian Day conversion Disputed (Again)

Thank you very much to User:Jc3s5h for replacing the formulas with new ones. Unfortunately, my computation shows it is wrong again. The error is only tiny so it's probable there is simply a piece of relevant information missing from the article to explain the difference. I'll freely admit my math is weak but these are simple sums to turn into computer code and I cannot see how I'd have made an error. Either way, please don't remove the dubious tag without explaining why my proof is invalid if you wish to remove it. If you see no problem with my proof then we will have to use the NOAA formula (which I know is inaccurate even in fairly recent history, but it's not inaccurate for today). So, here is my Python code testing the formula against one another:

from math import floor
import time
# Simple, easy conversion from another consecutive source
year, month, day = 2009, 9 , 9
print "Simple conversion from unix-time: %f" % (
    2440587.5 + time.mktime((2009,9,9) + (0,)*6) / 86400)
# This is from serveral places, including the American NOAA
y, m, d = (year, month, day)
if m < 2:
    y -= 1
    month += 12
a = y /100
b = 2 - a + (a / 4)
print "Most common method: %f:" % (floor(365.25 * (y + 4716)) +
    floor(30.6001 * (m + 1)) + d + b - 1524.5)
del a, b
# This is your new method, using integer arithmetic (copy/pasted) and with
# 2 regexps applied to change multiplication/subtraction symbols to * and -:
Y, M, D = (year, month, day)
JD = (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
print "Your method using integer math: %f" % JD
del Y, M, D, JD
# This is the above method, using floating point math.
# It is just the above formula with a regex applied in vi to make the numbers
# floats: :s/\([0-9]\)\([^0-9]\|$\)/\1.0\2/g
#
# If you don't know python, the map call below will make Y M and D floats too.
Y, M, D = map(float,(year, month, day))
JD = (1461.0 * (Y + 4800.0 + (M - 14.0)/12.0))/4.0 +(367.0 * (M - 2.0 - 12.0 * ((M - 14.0)/12.0)))/12.0 - (3.0 * ((Y + 4900.0 + (M - 14.0)/12.0)/100.0))/4.0 + D - 32075.0
print "Your method using floating point math %f:" % JD

The results of running this program are:

Simple conversion from unix-time: 2455083.500000
Most common method: 2455083.500000:
Your method using integer math: 2455086.000000
Your method using floating point math 2455084.248125:

82.132.139.213 (talk) 09:42, 9 September 2009 (UTC)

Before I consider the contents of your calculations, I will inform you that no Wikipedia editor, including you and I, are reliable sources of information. The formula is marked as dubious was copied from the Explanatory Supplement to the Astronomical Almanac. There is a footnote citing this source. Your dubious tag is unacceptable unless you go to the library, get the source, and find that the formula was not copied correctly. Therefore, I have removed the dubious tag. --Jc3s5h (talk) 14:24, 9 September 2009 (UTC)

I don't understand Python well enough to understand exactly what the program is doing. However, your results clearly apply to a Julian Date, not a Julian Day Number, because they contain a fraction. The algorithim in the article is for a Julian Day Number, not a Julian Date. I have changed the notation in the article to clarify this. Note the source was published in 1991, and the IAU Information Bulletin No. 81 that is cited in the article, and which states the proper abbreviations, was published after the source, in 1998.

Finally, I understand that time.mktime is based on local time, not Universal Time. That might be a source of error. --Jc3s5h (talk) 14:50, 9 September 2009 (UTC)

Further: as the article states (and this is a close paraphrase of the source) "JDN [I just changed this from 'JD'] is the Julian Day Number, which pertains to the noon occuring in the cooresponding calendar date." So if you want to know what JDN goes with September 9, 2009, the calculation should be run for 12:00, not 00:00. --Jc3s5h (talk) 15:00, 9 September 2009 (UTC)

For a specific example, Doggertt states on page 600 "for example, the Julian day number of 1900 June 25 is 2448068, whereas the Julian date at noon is 2448068.0." --Jc3s5h (talk) 15:04, 9 September 2009 (UTC)

I disagree that it was unacceptable to use the dubious tag. When the NOAA appear to disagree with the information you had put into Wikipedia it is entirely reasonable to flag it is dubious.

But let's not quibble about the rules, especially as you were right and I was wrong :) In fact, it was due to two things, firstly I hadn't paid enough attention to the article stating your formula was for noon not midnight and secondly, for some reason in Python using integer math -5/12 equals -1 instead of 0 like C (ruby does this as well). They presumably do the sum as a floating point operation then use floor() on the result instead of just doing integer math. Strange decision, especially as they refer to it as integer math.

Here is a worked example for anyone who's interested. Not sure it deserves to be in the article but it won't hurt here:

JDN = (1461 × (2009 + 4800 + (9 − 14)/12))/4 +(367 × (9 − 2 − 12 × ((9 − 14)/12)))/12 − (3 × ((2009 + 4900 + (9 − 14)/12)/100))/4 + 9 − 32075
JDN = (1461 × (2009 + 4800 + (9 − 14)/12))/4 +(367 × (9 − 2 − 12 × (−5/12)))/12 − (3 × ((2009 + 4900 + −5/12)/100))/4 + 9 − 32075
JDN = (1461 × (2009 + 4800 + −5/12))/4 +(367 × (9 − 2 − 12 × 0))/12 − (3 × (6909/100))/4 + 9 − 32075
JDN = (1461 × 6809)/4 +(367 × 7)/12 − (3 × 69)/4 + 9 − 32075
JDN = 9947949/4 +2569/12 − 207/4 + 9 − 32075
JDN = 2486987 +214 − 51 + 9 − 32075
JDN = 2455084

82.132.136.205 (talk) 20:38, 9 September 2009 (UTC)

AD ASTRA SCIENTIA (talk) 02:12, 29 April 2011 (UTC)

The formula works, but you have to discard the decimal part of the divisions (including for the variables a, m, and y). Of course, to get the correct JDN, you must use the date in UT or UTC, not local time.

Algorithm for converting JDN to Julian-Calendar Date?

Thank you for the algorithm for converting JDN to Gregorian Date and the accompanying explanation. (The Fliegel & Van Flandern formula on page 604 of the Explanatory Supplement to the Astronomical Almanac (USA) is too cryptic to understand.) However, I think one part of the explanation given here may be wrong (the intention is certainly unclear, IMO.) This is the explanation added in parentheses to dot-point four for the reduction "to a maximum of three".

(this reduction occurs for the last day of a leap centennial year where c would be 4 if it were not reduced)

Can you provide an algorithm along the same lines for converting JDN to a date in the Julian calendar.

I have code here that works. It is similar to the Fliegel & Van Flandern formula for the Gregorian conversion, but is just as cryptic:

sub JDNtoJulianDate (JDN, Y, M, D)
'   ---------------
'   Adapted from: http://dev.remotenetworktechnology.com/wsh/jdn.htm
'   Similar to the Fliegel & Van Flandern method for Gregorian dates.
'   Language: PowerBasic. (The symbol \ denotes an integer division.)

    Local J, K, L, N, I

    J = JDN + 1402
    K = (J - 1) \ 1461
    L = J - 1461 * K
    N = ((L - 1) \ 365) - (L \ 1461)
    I = L - 365 * N + 30
    J = (80 * I) \ 2447
    D = I - ((2447 * J) \ 80)
    I = (J \ 11)
    M = J + 2 - 12 * I
    Y = 4 * K + N + I - 4716
end sub   '  JDNtoJulianDate  ---------------------------------------

Thanks. Mottelg (talk). —Preceding undated comment added 01:52, 16 October 2009 (UTC).

---

Hi Folks, new to wikipedia here, so bear with me.

I've noticed that in this equation:

JDN = (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

The second term (367 × (M − 2 − 12 × ((M − 14)/12)))/12
reduces to the constant 367 as follows:
(367 × (M − 2 − 12 × ((M − 14)/12)))/12
(367 × (M − 2 − (M − 14)))/12
(367 × (M − 2 − M + 14))/12
(367 × (−2 + 14))/12
(367 × 12)/12
367

Which could then be combined with the final term as such:
JDN = (1461 × (Y + 4800 + (M − 14)/12))/4 − (3 × ((Y + 4900 + (M - 14)/12)/100))/4 + D − 31708

I have verified this result for a handful of dates against the original equation, the Naval Observatory NOVAS software (http://aa.usno.navy.mil/software/novas/novas_info.php) and their Julian Date page which you already reference (http://aa.usno.navy.mil/data/docs/JulianDate.php)

I suspect the original equation was transcribed directly from reference cited. Is there any reason not to apply this basic algebraic simplification?

Also note that different characters are used for the minus sign in the page as written, which causes issues when cutting & pasting into some tools. This is what it looks like pasting into nedit - a basic Linux text editor. I got a similar result pasting into excel:

JDN = (1461 × (Y + 4800 + (M \u2212 14)/12))/4 +(367 × (M \u2212 2 \u2212 12 × ((M \u2212 14)/12)))/12 \u2212 (3 × ((Y + 4900 + (M - 14)/12)/100))/4 + D \u2212 32075

If we replace this \u2212 symbol with a minus sign and replace the 'x' symbol with an * then users could simply copy and paste the formula into various tools and have it work, if the variables are defined correctly. The final result would be:

JDN = (1461 * (Y + 4800 + (M - 14)/12))/4 - (3 * ((Y + 4900 + (M - 14)/12)/100))/4 + D - 31708

I noticed somebody above posted some code - here's a listing of a program with this equation cut-and-pasted in and the results. I did have to make some of the constants floating point to force it to calculate the floating point answer, or you'd get integer math issues.

#!/usr/bin/python

import sys
import string

Y = string.atoi(sys.argv[1])
M = string.atoi(sys.argv[2])
D = string.atoi(sys.argv[3])

print "Gregorian Date:\t", Y, "-", M, "-", D

#Original Formula
JDN1 = (1461.0 * (Y + 4800 + (M - 14)/12))/4 +(367 * (M - 2 - 12 * ((M - 14)/12)))/12 - (3.0 * ((Y + 4900 + (M - 14)/12)/100))/4 + D - 32075

#Simplified Formula
JDN2 = (1461.0 * (Y + 4800 + (M - 14)/12))/4 - (3.0 * ((Y + 4900 + (M - 14)/12)/100))/4 + D - 31708

print "Orginal Formula:   \t", JDN1
print "Simplified Formula:\t", JDN2

print "Percent Error: \t", 100.0*(JDN1 - JDN2)/JDN1
print "Absolute Error:\t", (JDN1 - JDN2)

My $0.02 Thanks Eric --Ergeorge (talk) 21:55, 9 February 2010 (UTC)

I hope you noticed the note: "integer division is used exclusively, that is, the remainder of all divisions are dropped". I'm not sure your simplification is valid for integer division.

The algorithm is indeed copied from Doggett. He credits it to Fliegel, H. F. and Van Flandern, T. C. (1968), "A Machine Algorithm for Processing Calendar Dates," Communications of the Association for Computing Machinery, 11, 657. I suggest you look up that paper to see why the algorithm isn't simplified any further. Jc3s5h (talk) 22:17, 9 February 2010 (UTC)

A good citation to the Fliegel article is: --Drf5n (talk) 17:38, 28 June 2013 (UTC)

I have corrected the minor error in the journal title above. Kkddkkdd (talk) 13:20, 8 April 2013 (UTC)

Nevermind - I did some more testing and figured it out for myself. There's some integer math voodoo that goes on in that second term - if you do everything in integer math and strict order of operations, it doesn't always drop out. Very elegant - I think I will get that paper and take a look at the derivation. This also explains some of the questions in the section above (which is where this should have been posted - clicked the wrong edit). You can't do this as a floating point calculation. --Ergeorge (talk) 22:44, 9 February 2010 (UTC)

Chronological Julian Date?

As far as I can tell "Chronological Julian Date" was created by Peter Meyer, and all the sources for it seem to either refer to his web page, or are Wikipedia mirrors. I would like to see some independent evidence that this date is widely used by this name.

I wouldn't be surprised if some historians have adapted the concept of a Julian Date to a particular location and considered the day to change at local midnight rather than local noon. What would surprise me is if they consistently referred to this as a Chronological Julian Date. Jc3s5h (talk) 23:03, 7 February 2010 (UTC)

I recently edited the epoch entry for the Chronological Julian Day (CJD) from "00:00 January 1, 1, Monday" to "00:00 January 1, 4713 BC, Monday". This corrects an error that had slipped in at this edit, and restores the articles agreement with other sources. I am removing the "dubious" template. --SteveMcCluskey (talk) 23:11, 7 February 2010 (UTC)

After my edit I saw Jc3s5h's query. The CJD is used in the CÆSAR Code package developed by Michael L. Hall at Los Alamos National Laboratory and in the Sage-ST Time Library developed at the Idaho National Engineering Laboratory. That seems to give it some credibility and notability. I came to this article to check out my own vague recollection of a midnight epoch Julian Day Number so (FWIW) I had heard of this before too. --SteveMcCluskey (talk) 23:34, 7 February 2010 (UTC)

The www.lanl.gov/Caesar/node202.html link is not persuasive for several reasons. It is hidden away in a code package that is mainly concerned with other matters. The only sources it cites with respect to CJD are Peter Meyer and Wikipedia. If this software package were widely used by historians, chronologists, or people in related fields, in a way that they would be explicitly aware of the meaning of this term, that would be different. Jc3s5h (talk) 23:37, 7 February 2010 (UTC)

Why are you limiting your concern to use by "historians, chronologists, or people in related fields"? The concept seems to apply to anyone concerned with time series data.

You may be right that Peter Meyer originated the concept, but is that at all relevant? The concept is useful and is apparently being adopted. It would be a disservice to remove this useful concept from Wikipedia. --SteveMcCluskey (talk) 23:59, 7 February 2010 (UTC)

I just found this reference where Meyer states that the CJD originated with him. Knowing that, what would you recommend? --SteveMcCluskey (talk) 00:06, 8 February 2010 (UTC)

The main users of JD related concepts seem to be astronomers and related fields, and history and related fields. The astronomers always seem to use Greenwich-based dates, except as a first or last step in converting a local observation to a more standard frame of reference. I would expect people writing about human events at a particular time and place to be the ones apt to adopt a concept along the lines of CJD.

I notice that the description in the Wikipedia article and the Caesar software site differ from Meyer's site; the former treat it as an integer while Meyer treats it as a real number.

Meyer seems to know quite a bit about calendar issues, and his site has been cited by a number of reliable sources. He is certainly free to propose time scales or terminology if he feels there is a place for them. But encyclopedia's don't report proposals that have not achieved reasonably widespread adoption. It is appropriate for Wikipedia to provide information about proposals our readers heard about somewhere else; but if the vast majority of readers first hear about CJD here (or at mirror sites) then Wikipedia is promoting a nearly unknown proposal, not reporting on it. So the question to be resolved is how much has CJD been adopted among relevant communities? Jc3s5h (talk) 00:22, 8 February 2010 (UTC)

The big difference between the astronomers' concept and Meyer's is that the astronomers use a noon based epoch, stemming from the noon-based definition of astronomical time in which the day changed at noon (which was only changed to a midnight epoch in conformity with civil time on January 1, 1925). It is historically interesting that the American Astronomical Society's Committee discussing the changeover opposed in 1919 the Royal Astronomical Society's 1918 recommendation to retain the midnight epoch for the system of Julian Days.

I will move the entry for CJD to the bottom of the variants on the Julian Day, and add a note about its origins and status. --SteveMcCluskey (talk) 14:17, 8 February 2010 (UTC)

Is there a reference for this, so we can put it in the article? --Nike (talk) 01:21, 23 July 2012 (UTC) JD 2456131.556

Mistake in decimal calculation?

"A Julian date of 2454115.05486 means that the date and Universal Time is Sunday January 14, 2007 at 13:18:59.9."

Shouldn't this be something like 2454115.5486 (note the decimals)? —Preceding unsigned comment added by 77.167.55.199 (talk) 02:27, 8 February 2010 (UTC)

No, because the Julian day begins at noon. Jc3s5h (talk) 03:51, 8 February 2010 (UTC)

History section

The history section mentions the link between the JDN count and the Julian Period invented by Joseph Justus Scaliger. As the article states, the first year of the Julian Period (4713 BC) was the last time when all three of the Indiction, Metonic and Solar cycles were in their first year together. This implies that at some stage there was some common convention as to a starting point for those cycles.

My question is where are the references documenting how those cycles were counted? The methods of counting them must have differed between different calendars. (For example, the Metonic cycle was used in the ancient Greek luni-solar calendar, and (much later) in the Jewish luni-solar calendar, and in the Christian ecclesiastical calendar for reckoning the dates of Easter. Yet, nowadays, the "Golden Number" of a year in the Christian calendar (which denotes its position in a Metonic cycle) does not match the position of the corresponding Jewish year in the Metonic cycles of the Jewish calendar.)

(a) If 4713 BC was year 1 of a 28-year Solar cycle of the Julian calendar and of a Metonic cycle, it follows that (counting from that year), the first year of Solar cycle 170 is year 20 AD, and the first year of Metonic cycle 250 is year 19 AD. However:

(b) in the Jewish calendar, the Jewish year corresponding to AD 21 was year 1 of a 28-year Solar Cycle, all of which begin in Julian years of the form AD 28n+21. And the Jewish year corresponding to AD 22 is the first year of a Metonic Cycle, all of which begin with an AD year of the form 19n+3.

So, since there are clearly different conventions regarding this, according to which convention(s) used during or before Scaliger's time is (a) correct, and did any of them survive into the present era, i.e. are there any systems still in use today in which Solar Cycles of the Julian Calendar begin with AD years of the form 28n+20 and where Metonic Cycles begin with AD years of the form 19n? Mottelg (talk) 11:56, 2 March 2010 (UTC)

Scaliger ignored the Jewish calendar. His three cycles all appeared in late medival Latin computi. Specifically, the three cycles which Scaliger used in his Julian Period were the "decennovenal cycle" (19-year cycle) of medieval computists whose years were numbered by Dionysius Exiguus in 525 (these year numbers were named Golden Numbers in AD 1200), the solar cycle of late medieval computists, and the indiction. However, these medieval computists always mentioned another "lunar cycle" which neither they nor Scaliger used. The years of the decennovenal cycle were numbered in argument 5 of the "Nineteen year cycle of Dionysius" (years of the unused "lunar cycle" are numbered in argument 6). In modern notation the years of the decennovenal cycle are (Year mod 19) + 1. The years of the late medieval solar cycle in modern notation are ((Year + 8) mod 28) + 1. Although I have several citations for this solar cycle, I doubt that any are online. Some research is needed to find suitable online citations. — Joe Kress (talk) 10:18, 4 March 2010 (UTC)

Formula error

I think there is an error in the Gregorian - JDN calculation. The final constant should be 32077 to remove an error of 2 days. There is an even stranger error with the Julian - JDN calculation. According to http://aa.usno.navy.mil/data/docs/JulianDate.php :

JD	Date/Time from USNO	JD from Gregorian formula	JD from Julian formula
0.0	BCE 4713 January 01 12:00:00		2 0
1721423.00000	BCE 1 December 31 12:00:00		1721423
1721424.00000	CE 1 January 01 12:00:00		1721425 1721424
2299160.00000	CE 1582 October 04 12:00:00		2299160
2299161.00000	CE 1582 October 15 12:00:00	2299163 2299161
2455315.00000	CE 2010 April 28 12:00:00 (today)	2455317 2455315

Unfortunately, I don't have the reference used for these calculations (L. E. Doggett, Ch. 12, "Calendars", p. 604/6, in Seidelmann 1992) to check if the article has been vandalised sometime in the past. Astronaut (talk) 18:25, 28 April 2010 (UTC)

I have checked it against Doggett and I see no errors. Did you remember to do integer divisions, that is, ignore all the remainders? Jc3s5h (talk) 19:39, 28 April 2010 (UTC)

I thought I had used integer division with the INT function in Excel, 'til I realised I should have used the ROUNDDOWN function instead. Now I get the correct results. Thanks for the guidance and apologies for the confusion. The table above has been corrected should someone wish to use it. Astronaut (talk) 20:05, 28 April 2010 (UTC)

Julian Day to Gregorian

The program listed at http://www.astro.uu.nl/~strous/AA/en/reken/juliaansedag.html does not work correctly. It passes the few test vectors given, but if increment a JD value for a few years, you will eventually hit dates that generate nonsense like February 31. DonPMitchell (talk) 05:32, 14 May 2010 (UTC)

I browsed through the web page mentioned by DonPMitchell, and I didn't see anything I could just cut-and-paste into a C compiler. That means that when DonPMitchell adapted the information in the web page into a program, he could have made an error, so the problems he sees might come from the program, or might be from an error he made. Jc3s5h (talk) 13:05, 14 May 2010 (UTC)

Bug in formula

In the formula for converting julian days to Gregorian dates, there appears to be a bug on this line:

• let m = (da × 5 + 308) div 153 − 2; (note: this is the integer number of full months elapsed since the last March 1 at 00:00 UTC);

When this formula is used, it sometimes gives dates like April 0 instead of March 31. The cause is the imprecise nature of floating-point computations. It is effectively dividing 5 by 153, or dividing the unmultiplied number by 30.6. On a modern computer, 153/5 does not equal 30.6 precisely. In his book Astronomical Algorithms, Meeus discusses this problem and avoids it by using the constant 30.6001 instead of 30.6 (which is equal to 153/5).

Meeus' intermediate formula that extracts the month is E = INT(some value/30.6001). It does not perform integer division, but accomplishes the same effect by using the INT function, which is the same as the FLOOR function for positive numbers.-- B.D.Mills  (T, C) 23:31, 24 May 2010 (UTC)

Did you read this statement, which appears in the article: "The calculations below (which use integer division [div]"? Jc3s5h (talk) 00:10, 25 May 2010 (UTC)

Not all computing environments provide proper support for integer division. In such cases it is necessary to use floating point and then take the integer part of the calculation. I do not like such environments but at times we must use them. When implemented on such an environment, it is not robust.

There are other issues with this section that I will discuss below.

• Shifting of the calculation back to year -4800 is an ugly hack that does not do a good job of avoiding the problem of working with negative Julian dates.
• Let J = JD + 0.5: If we are careful to specify integer calculations, surely it is better to begin all the calculations with an integer here?
• The calculation given does not have proper in-text citations anywhere in the section. Where did this come from?

Based on my experiments, I do not feel that this algorithm is as trustworthy as the one given by Meeus. Although Meeus' algorithm is more opaque, it is shorter and is rigorous. Meeus states that his algorithm is not suited for negative Julian day numbers but nevertheless Meeus' algorithm does seem to work fine with them if using a function where INT() = FLOOR() for negative numbers. Meeus' algorithm also handles the transition between the Julian and Gregorian calendars while this algorithm does not. -- B.D.Mills  (T, C) 01:47, 25 May 2010 (UTC)

"Meeus' algorithm also handles the transition between the Julian and Gregorian calendars while this algorithm does not." That's the whole point. Astronomers use the mainstream proleptic Julian/Julian/Gregorian calendar and this algorithm tells you how to convert to or from the rarely used proleptic Gregorian calendar. Senor Cuete (talk) 21:29, 30 November 2011 (UTC)Senor Cuete

I used the algorithm given to write a C function:

void jDToProlepticGregorianDate(double jDNum, int *month, double *day, int *year)

{

   int j, g, dg, c, dc, b, db, a, da, y, m;
   double J, d, T;
   
   J = jDNum + 0.5;
   j = J + 32044;
   g = j / 146097;
   dg = j % 146097;
   c = (dg / 36524 + 1) * 3 / 4;
   dc = dg - c * 36524;
   b = dc /1461;
   db = dc % 1461;
   a = (db / 365 + 1) * 3 / 4;
   da = db - a * 365;
   y = g * 400 + c * 100 + b * 4 + a
   m = (da * 5 + 308) / 153 - 2;
   d = da - (m + 4) * 153 / 5 + 122; //Won't correctly calculate the fraction of a day
   T = jDNum - (int)jDNum;  //fractional part of the Julian day number
   T -= 0.5;  //because the Julian day starts at noon
   if(x < 0.0)
       T += 1;
   d += T;   //add fraction of day
   *year = y - 4800 + (m + 2) / 12;
   *month = (m + 2) % 12 + 1; 
   *day = d + 1; //Will be the correct day number if d is calculated as an int

}

The method in the article produces the correct answer EXCEPT for the fact that the calculation of d will only calculate the whole day number. In order to calculate the day with the fraction of the day I had to add the variable T and use it to calculate the fraction of the day as noted in the text after the algorithm. The note that the step that calculates d is misleading because it calculates only the whole day number -1. Should I edit the note? Also how can I enter the brackets in this section so that they don't create that annoying box? Senor Cuete (talk) 02:29, 27 November 2011 (UTC)Senor Cuete

I wrote a C function to convert dates in the proleptic Gregorian calendar to Julian day numbers: double ProlepticGregorianDateToJDN(int year, int month, double day) {

   int a, y, m;
   
   a = (14 - month) / 12;
   y = year + 4800 - a;
   m = month + 12 * a - 3;
   return((day + ((153 * m + 2) / 5) + (365 * y) + (y / 4) - (y / 100) + (y / 400) - 32045) - 0.5);

} Notice that one has to subtract 0.5 from the result of the last calculation in the formula given in the article to make the fraction of a day come out correctly. This is because the algorithm fails to account for the fact that the Julian day starts at noon. Senor Cuete (talk) 14:18, 30 November 2011 (UTC)Senor Cuete

The formula in the article to convert Gregorian day, month, and year to Julian Day Number is correct. Notice the article states "The Julian Day Number (JDN) is the Julian day with the fractional part ignored." Your algorithm is for some other calculation because the result is a double. If your algorithm were applicable to finding Julian Day Number its result would be an integer. Jc3s5h (talk) 16:11, 30 November 2011 (UTC)

No, you're mistaken. A Julian day number is not an integer. It's a real number which represents the number of days, including the fraction of a day, elapsed since a fundamental epoch. Other algorithms in the article convert to / from Julian day numbers and this one should as well. Senor Cuete (talk) 19:23, 30 November 2011 (UTC)Senor Cuete

Please read citation #4 in the article. Search for "APPENDIX: PROPOSED DEFINITIONS" within the PDF. According to that source, JDN is an integer. Then go to the glossary of the Astronomical Almanac 2012 and look up Julian day number. That source also says it's an integer. Where is your source that says otherwise? Jc3s5h (talk) 20:00, 30 November 2011 (UTC)

Julian day numbers are the Rosetta Stone of converting among calendars and doing astronomical calculations. All astronomical calculations are based on Julian day numbers. Astronomers describe a time of observation as a number of days and a fraction of a day from a fundamental epoch. They chose noon January 1st, -4712 Greenwich Mean Time. The Julian day starts at noon because they were interested in things that were visible at night. The number of days elapsed since this time is a Julian day number. A good reference is: Meeus, Jean (1991) Astronomical Algorithms. Second edition with corrections as of August 10, 2009 Richmond: Willman-Bell. ISBN 0-943396-61-1. I highly recommend Astronomical Algorithms for its excellent and complete list of algorithms with examples and pseudo-code. This Wikipedia article is very useful because astronomers don't use the Proleptic Gregorian calendar. They use the mainstream proleptic Julian/Julian/Gregorian calendar. The proleptic Gregorian calendar is rarely used; It's used for Maya calendar conversions by some mayanists and it can be used as an ISO standard calendar if both parties agree to use it. For these reasons it's difficult to find algorithms for converting to or from the proleptic Gregorian calendar. I had to do it for a project and since my books about astronomical algorithms didn't discuss it, I found this Wikipedia article useful and I thought the two functions I wrote might help someone else who read this article. The reason for the confusion might be the difference between the Julian day and a Julian day number which IS a double. Any function that returns a double can be rounded to an int (remembering that a Julian Day number is based on noon) if needed but it will be useless for most purposes if it ignores the fraction of a day. Senor Cuete (talk) 21:15, 30 November 2011 (UTC)Senor Cuete

You are making general statements about Julian whatever. I am making a very specific claim which I have backed up with sources. I claim that astronomers use two different terms, "Julian day" which is a real number, and "Julian day number" which is an integer. This corresponds to the way a programmer would declare one variable as a double and another variable as an integer. Unfortunately I do not have access to the Meeus. Would you please quote the definition of "Julian day number" from the book and give the page number where it appears? Jc3s5h (talk) 21:33, 30 November 2011 (UTC)

I'm pretty sure that the text I used is plagiarized from Practical Astronomy with your Calculator by Peter Duffet-Smith. I don't have my copy of Meeus here but I'll get it - be patient. You're probably right that a Julian day is a double and that a Julian day number is an int. Either way a function that returns a double is much more useful since a double is required for astronomical calculations and it can be rounded to an int. Stay tuned. Senor Cuete (talk) 23:37, 30 November 2011 (UTC)Senor Cuete

Looking at the references to which you referred me, I see that in 1998 it was resolved that a Julian date is a floating point number and a Julian day number is an integer, so you are right. When I first wrote the software to create ephemerides in about 1988 these terms were used more carelessly so I didn't know about the strict definition used today. The article is erroneous because the algorithm for converting a Julian day number to the (proleptic if needed) Gregorian calendar actually converts a Julian DAY to a Gregorian DAY NUMBER (but provides the information, using the variable T) to get a (proleptic if needed) Gregorian DAY. I can infer that a Gregorian DATE is a DAY NUMBER but I don't see where it says this in the article and this is inconsistent with the definition of a DATE as a floating point number. My two functions then convert a Julian DAY to a Gregorian DAY and a Gregorian DAY to a Julian DAY. Should I change the identifiers of the functions? Senor Cuete (talk) 01:10, 1 December 2011 (UTC)Senor Cuete

If you are asking about what should go in the article, anything in the article should come from a reliable published source. The algorithms in the article that lack such sources should be removed until they can be replaced by algorithms from reliable sources. Jc3s5h (talk) 02:04, 1 December 2011 (UTC)

Possible Omission?

Apparently there is another, less involved use of the term "Julian Date" in industry which simply seems to be the counting of days from January 1 of each calendar year, ending with 365 (366 in leap years) on December 31. I was made aware of this because of articles in the media on the recent salmonella contamination of eggs from Iowa. This seems to be a legitimate inclusion on this page, or there needs to be at least a further disambiguation article about this usage at the top of this article.Robert Johnson (talk) 10:14, 20 August 2010 (UTC

In the Julian Date section see the description of ordinal date. Jc3s5h (talk) 11:04, 20 August 2010 (UTC)

Formula changes

In this edit User:RadioFan has changed from a clearly reliable source, The Explanatory Supplement to the Astronomical Almanac, to a self-published website by Claus Tøndering. Granted, this website is often cited by serious publications, but still, the WP:IRS guideline would clearly rank it below a book by a recognized scientific publisher.

In addition, the new edit does not follow the established citation style of this article.

So my question is, should the edit stand? Jc3s5h (talk) 16:11, 21 September 2010 (UTC)

I understand your question about the source, is there a question about the accuracy of the formula? Is either more or less accurate?--RadioFan (talk) 16:35, 21 September 2010 (UTC)

I don't know if the new version has any difference in accuracy. I think the whole point of WP:IRS is to avoid the need for me to test the formula from the less reliable source, and avoid the need for any reader to believe I did it right. Jc3s5h (talk) 16:50, 21 September 2010 (UTC)

This webpage is cited by a Java Language book authored by 2 Princeton professors and by the U.S. Naval Observatory as a source for Julian date conversion formulas. I see no issues with the reliability of this source. The cited formula improves the article with better formatting and a slightly simpler, clearer formula. The almanac isn't any more reliable because it's printed as both sources have been embraced widely enough to be considered reliable.--RadioFan (talk) 12:08, 22 September 2010 (UTC)

Food Industry

In the food and grocery industries the term "Julian date" is used as follows: 001 is January 1 and 365 is December 31 (unless it is a leap year and then it is 366). An example of the term being used in such a manner by a respectable source is [1]. Typically a Julian date is used to code a pack date. (On the rare occasions which dates are not coded in this manner, it is my experience that consumers mistake it for the expiration date.) Maybe the article should mention this usage of the term as well. 68.97.10.193 (talk) 23:22, 3 February 2011 (UTC)

The article already mentions similar usage in the Julian Date section thus: "The use of Julian date to refer to the day-of-year (ordinal date) is usually considered to be incorrect although it is widely used that way in the earth sciences and computer programming." I'm adding food industry and your ref. The day-of-year is called the ordinal date in ISO 8601. — Joe Kress (talk) 07:19, 4 February 2011 (UTC)

Algorithm for calculating JDN using Microsoft QuickBASIC

This algorithm pertains to the Gregorian Proleptic Calendar. The months (M) January to December are 1 to 12. For the year (Y) astronomical year numbering is used, thus 1 BC is 0, 2 BC is −1, and 4713 BC is −4712. D is the day of the month from 1 to 31 as applicable. JDN is the Julian Day Number, which pertains to the noon occurring in the corresponding calendar date.

It is necessary to use the function for Long Integers in the first line of code. This enables integers in the range of -2,147,483,648 to 2,147,483,647[2] to be processed. Integer division is commanded by using the back slash "\" character instead of the forward slash "/".

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
DEFLNG A-Z
INPUT "Day";d
INPUT "Month";m
INPUT "Year";y
a=(14-m)\12
y=y+4800-a
m=m+12*a-3
j=d+(153*m+2)\5+365*y+y\4-y\100+y\400-32045
PRINT "Julian Day Number =";j
END
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The Algorithm should return the following values as a cross check:-
JDN of 24 NOV, -4713 is 0 (4714 BC Gregorian Proleptic Calendar)
JDN of 15 OCT, 1582 is 2,299,161 (beginning of the Gregorian Calendar)
JDN of 16 NOV, 1858 is 2,400,000
JDN of 01 JAN, 2000 is 2,451,545
JDN of 31 AUG, 2132 is 2,500,000
Summerdrought (talk) 21:20, 6 March 2011 (UTC)

I've checked the above algorithm but used Excel Visual Basic instead, so had to do some slight syntax adaptations, finding it works fine for all dates since oct. 15 1582. When tested with oct. 4 1582 it returns 2299150 when 2299160 is expected. Jeep IKA (talk) 13:25, 26 May 2011 (UTC)

The algorithm is wrong because there is an inadequate specification of the meaning of the inputs. In particular, "month" and "day of month" are not adequately defined. Jc3s5h (talk) 13:37, 26 May 2011 (UTC)

Jeep IKA, The algorithm pertains to the Gregorian Proleptic calendar, therefore if Oct 4, 1582 Gregorian had existed, it would be JDN 2299150, however Oct 4, 1582 was in the Julian Calendar. Hope this helps.

Jc3s5h, M is the day of the month from 1 to 12 as stated in the first sentence prior to my recent edit, I have added "from 1 to 31" for D is the day of the month, as suggested by you. The first sentence was copied directly from the main article, therefore your comment should apply to it also. Summerdrought (talk) 08:10, 29 May 2011 (UTC)

No calendar date is unambiguous unless you state which calendar you are using, or the circumstances clearly imply which calendar is being used. In the case of algorithms that are valid for long periods of time, which calendar to use is always ambiguous and must always be stated. Jc3s5h (talk) 13:31, 29 May 2011 (UTC)

Summerdrought , Jc3s5h thank both of you for clarifying, I got it. Jeep IKA (talk) 19:13, 30 May 2011 (UTC)

Negative Julian days

The article defines JDN as "The Julian day number (JDN) is the integer part of the Julian date (JD). The day commencing at the above-mentioned epoch is JDN 0. Negative values can be used for preceding dates..." According to this, the day preceding Julian day 0 is also Julian day 0. For example, while the integer part of Julian date 0.3 is 0, so is the integer part of -0.3. Clearly, what is intended is not the integer part but the "floor", that is, the greatest integer not greater than the Julian date. Unfortunately, this is not nearly as easy to express as "the integer part" is. I shall try a wording that gets around this. —Preceding unsigned comment added by 208.53.195.38 (talk) 17:40, 25 March 2011 (UTC)

Date format

I wonder if this article should use the more international date format of day month year. Julian days are used in astronomy, which is an international science. After all, the United States is nearly alone in its use of month day, year. —Preceding unsigned comment added by Kaptain Cirk (talk • contribs) 00:08, 19 May 2011 (UTC)

This has been discussed at length over a long many years at WT:Manual of Style (dates and numbers). The current resolution of the issue is contained at WP:STRONGNAT and WP:DATERET. Since you do not assert strong ties to a particular English-speaking country, I don't believe you proposal is in accord with "Manual of Style (dates and numbers)". The concept that all articles that are unrelated to a particular country should use the so-called international date style has been repeatedly rejected. Jc3s5h (talk) 00:18, 19 May 2011 (UTC)

Chronological Julian Day expanded concept

The Chronological Julian Day as suggested by Peter Meyer is a useful concept but I believe that its use is beyond that of the day in a particular time zone. It can be based on any form of local time, Local Mean Time, for example. Local time is an integral part of any calendar. The nychthemeron may begin at any point in the day/night cycle. The most common times to begin a cycle are midnight, noon, sunrise and sunset. Any of these points may be used in a Chronological Julian Day numbering system. Alexselkirk1704 (talk) 14:43, 27 July 2011 (UTC)

I don't understand where you're going with this. Wikipedia, as an encyclopedia, reports on what time scales have been created and used by a significant number of people. It is not the role of Wikipedia to propose extensions of time scales (or anything else). Jc3s5h (talk) 15:15, 27 July 2011 (UTC)

I believe that the concept of the local Julian Day is, in fact, used by a number of people. I have used a JD based on Local Civil Time and Local Mean time in my own calendar studies for several years before I saw the Peter Meyer paper. This use of a JD based on a time scale other than UT, UTC, TT or local zone is implied (I believe by Meyer himself) at http://www.hermetic.ch/cal_stud/jdn.htm#chronological . The Wikipedia article suggests that only the zone time is used in the Chronological Julian Day. I would suggest that any time scale may used and that the article should reflect that fact. Alexselkirk1704 (talk) 20:21, 27 July 2011 (UTC)

Article needs to be more focused and shorter

Do we really need the BASIC-ish pseudocode conversion methods in this article? It's not something that is terribly useful, from either a practical or programming standpoint, and in any case this seems to be the main point of contention in the article. Surely the formula given in a standard mathematical format is both more useful for non-programmers and programmers alike.

In addition, I don't see much in the article that clearly points out that the Julian day is not really a practical date system for general use, but is almost exclusively used for a reference point in orbital elements and ephimerides. The Julian day is not "heliocentric", does not rely on or make accomodations to the vagaries of Earth's orbit (referenced to TT and not UTC), and does not easily map to a calendar (It's "year" has fractional days, not leap days). Instead there seems to be much about the Julian calendar, which is certainly related, but not the topic of this article.

What do you think?Msaunier (talk) 11:19, 13 September 2011 (UTC)

I think that a lot of the math under the calculation section is tedious and not encyclopedic. I know that someone removed it a few months ago, and it got added back. --Nike (talk) 06:17, 21 July 2012 (UTC) JD 2456129.761

Msaunier - The math IS useful because it's not particularly easy to find it unless one has a book about astronomical algorithms. Yes anything-ish pseudocode is not very useful. Julian day numbers are practical for many purposes beyond those that you mention. For example, converting between different calendars. A date in some calendar is converted to a Julian day number, then to a date in the desired calendar. For this purpose Julian day numbers are a sort of Rosetta stone. Senor Cuete (talk) 18:11, 21 July 2012 (UTC)Senor Cuete

Being useful is not a sufficient criterion for being in an encyclopedia. An external link could be added, or if it has to be on Wikipedia, make it a separate article. Or just copy/paste it to your own computer. --Nike (talk) 22:15, 21 July 2012 (UTC) JD 2456130.427

UT1/TT

The article currently says

...recommends that Julian Dates be specified in Terrestrial Time, and that when necessary to specify Julian Dates using a different time scale, that the time scale used be indicated when required

and

A Julian date of 2454115.05486 means that the date and Universal Time is Sunday January 14, 2007 at 13:18:59.9.

These two seem to contradict each other; shouldn't the latter be Terrestrial Time? This amounts to a difference of over a minute. AxelBoldt (talk) 21:20, 19 November 2011 (UTC)

I notice the article only gives a vague allusion to the first recommendation coming from the IAU, with no specific source given. The second statement does specify UT, although the wording is awkward, so whether the first statement is true or not, there is no contradiction. Jc3s5h (talk) 01:59, 20 November 2011 (UTC)

I guess my problem is this: if someone says "the Julian date was 2454115.05486" then this is an ambiguous statement; it could mean JD(UT1) or JD(TT) with a difference of about a minute (or am I misunderstanding something fundamental here?). The IAU recommendation seems to resolve this in favor of JD(TT), i.e. for Julian dates I'm always to assume JD(TT) if no time scale is specified. But then later in the article we give a Julian date without time scale and arbitrarily resolve it as JD(UT). AxelBoldt (talk) 18:39, 20 November 2011 (UTC)

The Julian Date is used by two different communities. In astronomy, JD(TT) is required for precision when calculating the gravitational interaction of solar system bodies. But in calendars, JD(UT1) is required because calendars only count day and night on Earth, so Earth's slowing rotation must be included. Most of the present article discusses calendrical conversions. But calendars have no governing body, unlike the IAU in astronomy. Thus JD 2454115.05486 is assumed to be TT in astronomy but UT1 in calendrical calculations, unless otherwise stated. — Joe Kress (talk) 20:22, 20 November 2011 (UTC)

First reference

"The use of Julian date to refer to the day-of-year (ordinal date) is usually considered to be incorrect although it is widely used that way in the earth sciences, computer programming, military and the food industry.[1]"

This reference is misleading. While reading one would think that the contentious statement "is usually considered to be incorrect" would be the reason for the reference. But all the article does is reference the use of Julian day in best-used-by dating for eggs, which, really, is totally irrelevant to the use Julian day and whether it is an acceptable form ordinal days.

Davisrunning (talk) 18:19, 9 July 2012 (UTC)david july 9, 2012

Considered to be incorrect by whom? The definition of most words is usually determined by common usage, so that if that usage changes, the new definition becomes "correct". The exception is when some authority creates a definition, but that is then binding only on those subject to that authority. Could it not be possible that using the term for DOY/ordinal date is incorrect in one field, i.e. astronomy, but correct in another, i.e. food industry? Clearly, NASA and the IAU do not consider it correct. If some government or industry standards body defines Julian date in such a way, then that would be evidence that it is not universally incorrect. I just looked on the USDA web site and found a Julian date calendar, among other references. I do not see an official regulation with that definition but it is at least evidence of official usage. (Never mind the fact that it refers to the Gregorian, not Julian, calendar!) Apparently the US military also uses this definition, and I'd rather not argue with them.

I will change the wording so that it's not POV. --Nike (talk) 22:56, 21 July 2012 (UTC) JD 2456130.455 or 12202.955

Truncated Julian Dates

The table on "Alternatives" gives two definitions for TJD, one as JD - 2440000.5, "as introduced by NASA", and the other as JD mod 10000, "NIST definition". I have been unable to find the second definition anywhere online, at NIST or elsewhere. I recall when TJD rolled over in 1995, both definitions were used by different sites, even at NASA (A four-decimal day count originating at midnight 1968-05-23,24) but the four-decimal part may have referred only to TJD before 1995 since it became self-contradictory afterwards. Earlier versions of this article stated, "NIST treats it as cyclical". IIRC some did suppose that TJD was cyclical based upon the statement that it had only four digits, but I don't know any authoritative source, and it seems that Wikipedia and its copies are now the only reference to this definition. I can find references to five-digit TJDs, but no shorter ones after 1995. Therefore, unless anyone can find a reference I will delete the second definition. --Nike (talk) 05:54, 21 July 2012 (UTC) TJD 16129.245

Article cleanup

This article as a whole seems confusing and disorganized. I will attempt to clean it up a bit. I don't intend on making major changes, but you'll let me know if I get it wrong. --Nike (talk) 23:17, 21 July 2012 (UTC) JD 2456130.467

The lead now reads as if Julian dates are mostly used by astronomers and any other use of real Julian dates (not ordinal dates) is not worth mentioning. Also the definition would only apply to the way astronomers use Julian dates. But the Julian period was invented by a historian, for historians. It could still be used by historians and others doing calendrical calculations. I am uncomfortable dismissing these uses without researching the extent to which those groups use Julian dates, and if they are still in use in those fields, how they are defined. Jc3s5h (talk) 12:52, 22 July 2012 (UTC)

Strange, I don't think I changed much, aside from removing a few redundancies and moving things around. Please point out what specifically I changed that you don't like. If anything, I think I made it less exclusive. I changed "for scientific use by the astronomy community...recommended for astronomical use by the International Astronomical Union" (which suggests only astronomers) to "used primarily by astronomers".

In fact, Julian Dates are mostly used by astronomers. Julian day numbering was introduced by an astronomer, for astronomers, to date astronomical observations, and that is the way it has been used for over a century. The definition is taken directly from the International Astronomical Union. There is nothing in the definition which precludes non-astronomers from using Julian Dates, and I have not "dismissed" anybody. In fact, there is a mention of Chronological Julian Dates being used by calendar students, despite previous controversy about their notability, and I happened to expand on that just a bit. BTW, the article is Julian day, not Julian period. The Julian Period existed nearly three centuries before Julian days.

I have not come across any historians using Julian Dates, and just a few calendar students as are already mentioned. When you look at the literature (books and journals) practically all the notable references are astronomical. But we cannot say what any other groups are doing or how Julian Dates are used or defined in any other field without knowing what that is. If you wish to research how historians, etc., have used the Julian Period or Julian Dates, you are free to add to the article. Perhaps there could be a separate article for Julian Period, although I don't know what else there is to say about it. --Nike (talk) 13:51, 22 July 2012 (UTC) JD 2456131.077

Since all my history reading about topics old enough to benefit from Julian dates or the Julian period have been aimed at general readers, not historical scholars, I don't know if Julian dates or the Julian period is used by historians. Perhaps I'll stop by the local college library and see if I can find something that informs me what historical scholars usually do. Jc3s5h (talk) 16:01, 22 July 2012 (UTC)

Since "Julian Period" redirects here, perhaps we should include more about it. I looked in Britannica and it says, "Julian period, chronological system now used chiefly by astronomers and based on the consecutive numbering of days..." I am now reading Scaliger's book. --Nike (talk) 20:09, 22 July 2012 (UTC) JD 2456131.339

A standard reference for the use of Julian day numbers in calendrical calculations is Kalendariographische und chronologische Tafeln by Robert Schram (1908), which is a set tables of JDNs for the beginning of every month in many calendars over thousands of years. Prior to the introduction of JDNs, the year of the Julian Period was used by most historians to date events, but is no longer used to my knowledge. As an example, see the two images (Latin and English) on the first page of the Ussher chronology where all events in the entire book are dated by both BC/AD years and the year of the Julian Period. A current calendrical use of JDNs is for correlation constant in Maya chronology, which is the JDN of the first day of the the Maya Long Count, 13.0.0.0.0. Although many have been proposed, the most often used correlation is JDN 584,283 for 11 August 3114 BC Gregorian. — Joe Kress (talk) 06:17, 23 July 2012 (UTC)

I was having a hard enough time with Latin... --Nike (talk) 06:58, 23 July 2012 (UTC) JD 2,456,131.79

Does Schram (1908) consider the Julian day to begin at 12 h UTC? How does Schram deal with start-of-day conventions in various calendars and cultures? (Sorry, I don't read German.) Jc3s5h (talk) 11:54, 23 July 2012 (UTC)

Google Translate works much better with German than Latin. But from what I can tell, it's not much of an issue. He does, at one point, talk about Julian days starting at midnight, so .25 is 6 am, .5 is noon, etc. --Nike (talk) 01:13, 24 July 2012 (UTC) JD 2456132.55

That's a start. Another question is whether Schram considers midnight to be local midnight or midnight at the meridian of Greenwich. And of course I ought to have asked about 12 h UT, not UTC. Jc3s5h (talk) 15:04, 24 July 2012 (UTC)

Why don't you run it through Google Translate, as I suggested? In any event, I don't see how it's relevant to the article. --Nike (talk) 21:04, 24 July 2012 (UTC) JD 2456133.377

I wouldn't trust machine translations to gather specific detailed facts, only to get a general idea of what a passage is about. It is relevant to this article because it matters whether a community that uses Julian dates with a start-of-day that either differs from 12 h or differs from UT. Jc3s5h (talk) 21:09, 24 July 2012 (UTC)

I don't see how, and one author a century ago hardly constitutes a community in any event. But you might like this page which states, "The Julian Period Year is rarely used (except in the Old Farmer’s Almanac), but the strict count of days is widely used among astronomers, calendar freaks and Mayanists (not that that really encompasses that wide a constituency, by most definitions)." --Nike (talk) 21:47, 24 July 2012 (UTC) JD 2456133.407

New algorithm reverted

I have reverted a new algorithm introduced by User:Marlin Woks for several reasons:

• There is no citation to the source of the new algorithm
• It is not obvious there is any reason for the new algorithm, which seems to be designed to automatically change depending on whether a given date is Julian or Gregorian in a certain jurisdiction. But I seriously doubt the types of people who use this kind of algorithm, such as astronomers, would want to tie themselves to any particular jurisdiction. Hence I doubt this algorithm is worth including.
• The description is wrong; it is placed so that it implies that algorithms that work perfectly fine with proleptic Gregorian dates won't work.
• There are citations to Wikipedia articles; this is not allowed. See WP:CIRCULAR. Jc3s5h (talk) 15:05, 21 August 2012 (UTC)

I changed the algorithm for the following reasons:

• The source for the maths was the same as the current source. I marked it dubious as it contains references to floored division, when this is incorrect, even though in the notes it refers to the floor brackets as integer division (also incorrect) In addition I added a university web-site source that explains each individual step. The pseudo-code algorithm, was derived from the maths.
• The jurisdiction is relevant to those countries that actually marked the change from Julian to Gregorian. Those that didn't do not use the Julian Day Number format so jurisdiction is therefore irrelevant.
• The current one does not give 1st Jan 4713 BCE as Julian Day Number zero. This is incorrect by definition; the only way of getting this right is to determine the change from Julian to Gregorian
• The current one does not take into account the change in leap year handling in the Julian Calendar, and the additional handling in the Gregorian calendar even though the source mentions it.
• The kind of people who use this include computer programmers; indeed, that is why I changed the existing procedure - I am a computer programmer - and I realised that the current one is incorrect.
• The existing algorithm doesn't take into account BCE years. For sure, it mentioned that one can mess around with years *before* plugging it into the algorithm, but this is unnatural, and should be rejected.
• The existing algorithm claims to be valid since sometime in 4800 BCE (derived from the dubious source, no doubt) This is patently wrong.

Sorry, I didn't realise that Wikipedia articles couldn't be referenced. Marlin Woks (talk) 15:20, 21 August 2012 (UTC)

I have incorporated the reference to the CS 1063 project page at the UT San Antonio computer science department as a citation, since it provides a helpful explanation of the variables. Please keep in mind that Wikipedia editors have no credibility and no one should trust a Wikipedia editor to make correct changes to a published algorithm. All algorithms should be cited to reliable sources, as explained at WP:V and WP:IRS. It's OK to say that an algorithm is wrong in a talk page, and use that discussion process to evaluate various published algorithms to decide which one to put in the article, but algorithms invented by editors shouldn't go into articles.

Your claim that the article, as it was before your changes, does not work for Julian Day Number 0 is incorrect. The heading says "Converting Gregorian calendar date to Julian Day Number". When the Gregorian date that corresponds to JDN 0, 24 November -4713, is substituted into the algorithm, the result is indeed 0.

Your claim that Tondering uses incorrect floor symbols ignores the convention that a writer may define symbols to have any meaning he wants within a given piece of writing. So long as the special definition is clearly set forth, the fact that the customary use of the symbol is different is irrelevant. Jc3s5h (talk) 15:52, 21 August 2012 (UTC)

• According to your own source - http://books.google.co.uk/books?id=TD0CAAAAYAAJ&pg=PA595&redir_esc=y#v=onepage&q&f=false -the Julian Day Number era began 1st Jan 4713 BCE not 24 Nov 4713 BCE. If Hershel is wrong, and by extension, you are right, can you remove the Hershel source, please, if not only to stop me wasting my time.

• I should point out that the source for the algorithm makes the adjustment for pre 15th Oct 1582 plain and clear. Why is it that essential parts of algorithms can be removed (without notificaton) and when included back in, are removed? My version included all of the adjustments regarding Julian/Gregorian change, and years BCE expressed in mathematical form directly from the source.

• I take your point about the semantics of the original title.

• The only other time where I have seen the floor brackets used is with interval arithmetic; I didn't realise that radically non-standard mathematical symbol usage was allowed. Sorry. Marlin Woks (talk) 16:03, 21 August 2012 (UTC)

Your claim "According to your own source - http://books.google.co.uk/books?id=TD0CAAAAYAAJ&pg=PA595&redir_esc=y#v=onepage&q&f=false -the Julian Day Number era began 1st Jan 4713 BCE not 24 Nov 4713 BCE" is meaningless because you failed to label the dates with calendars, that is, Julian or Gregorian. Herschel was not so careless; the very web page you link to states, near the heading of the "First day current of the Era" column, states "Julian dates".

As for your statement "the source for the algorithm makes the adjustment for pre 15th Oct 1582 plain and clear", what source? What algorithm?

"If you are writing about your algorithm, I see no need to put it in Wikipedia. We have an algorithm for converting Julian dates to Julian day number. We have one for converting Gregorian dates to Julian day numbers. It is trivial for a programmer to write a program that determines whether the date is Gregorian or Julian in the situations the programmer is interested, and then invoke the appropriate algorithm. Wikipedia is an encyclopedia, not a collection of computer algorithms. Jc3s5h (talk) 17:23, 21 August 2012 (UTC)

I see that my statement above, "we have an algorithm for converting Julian dates to Julian day number", is wrong. We used to, but someone removed it without me noticing. So I have incorporated Tondering's formula to convert from Julian calendar dates into the section, and retitled the section accordingly. The section now has the same substance suggested by Marlin Woks, but is more concise. Also there is no unnecessary assumption that a programmer will write an algorithm to decide if the date is Julian or Gregorian; the method for determining that is left wide open, as it should be. Jc3s5h (talk) 18:03, 21 August 2012 (UTC)

As you say, it's not very encyclopedic. Let's just delete all the algorithms, and instead link to the reference(s). --Nike (talk) 18:56, 21 August 2012 (UTC)

I don't think it's unreasonable to include algorithms. Tondering's website, being a personal web site, may not be around in the long term. Some of the other references are expensive and hard to find. So I think it serves a purpose to make the algorithms available for free on an easy-to-find website, namely, Wikipedia. But only a few of algorithms should be presented; obvious variations should be excluded. Jc3s5h (talk) 19:06, 21 August 2012 (UTC)

I think the ommission of the maths would be a backward step, particularly, as has been said, finding it out by oneself is fraught with difficulty and expense. Indeed, the problem with Tondering's website is where did he get the maths from? It bears no relation to Hershel's work, which relies on look up tables, and, even, the Wikipedia link to ordinal day-numbers is only loosely related, but vital to the correct operation of the maths. I am wondering, also, whether the university link is warranted, since it doesn't account for dates in the Julian epoch even though it does specify the parameters for the Gregorian era. Certainly, it's a difficult one. I believe that this page is used extensively by people who need to implement some routine or another that spews out the Julian Day Number; that's astronomers, by convention, and computer programmers to circumvent the difficult issue of the non-uniform calendar system (ie ordinal days across year boundaries) in business systems - this is how I ended up becoming involved. Ideally, someone needs to write a paper on an open-source basis, that is peer-reviewed, that can be referenced. Marlin Woks (talk) 20:04, 21 August 2012 (UTC)

This link (http://www.astro.uu.nl/~strous/AA/en/reken/juliaansedag.html) seems to be broken Marlin Woks (talk) 21:17, 21 August 2012 (UTC)