Talk:Julian day/Archive 3

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

External link

Someone tried to add a link to their site, Julian-date.com, Jc3s5h wrote: "Site that doesn't know what MJD stands for probably isn't reliable enough to appear in external links." The site says "Modified JD", which is correct. I'm not sure it's the best link, but the reason to revert should be a valid one. --Nike (talk) 08:11, 6 October 2012 (UTC)

At the time I reverted it said military Julian date (but I don't recall how it was capitalized). Jc3s5h (talk) 13:38, 6 October 2012 (UTC)

I'm familiar with the site, and it did show "Modified JD (MJD)" separately from "Military Julian Date". It did have some errors in the past that were previously corrected, but that was not one them. I'm not advocating for the site; I think it's best to link to more established sites and I don't even try to link to my own page. We just need to come up with a better reason for rejecting it. --Nike (talk) 19:58, 6 October 2012 (UTC)

Well, there are a few problems I noticed right off:

• The text says it calculates since Greenwich noon of January 1, 4713 BC, but if you convert JD 0.001 (it doesn't work for JD 0), you get 24 November -4713. The author seems to see no need to state which dates are Julian and which are Gregorian.
• You can't easily cut-and-paste the output calendar date.
• You can't convert a calendar date for a year before -999.

Finally, it is the job of the editor who added it to convince other editors it is worth keeping. Jc3s5h (talk) 20:20, 6 October 2012 (UTC)

Vandalism

I can't figure out how or why, but there's some sort of vandalism occurring in the introduction:

"The Julian Period is a chronological interval of 7980 years beginning 4713 BC. It has been used by historians since its introduction in 1583 to convert between different calendars. GO FUCKING SHOVE YOUR DIKK IN A BITCH!"

I seem to have solved the problem by capitalizing: currentyear to become CURRENTYEAR

But I have absolutely no idea how it was changing into the expletive ridden sentence that it was. — Preceding unsigned comment added by 210.227.89.70 (talk) 06:31, 16 November 2012 (UTC)

Current Julian Day

The { { date } } and { { CURRENTJULIANDAY } } commands (and others) used throughout the article seem to be cached at the time date of article edition, so that they are incorrect when viewed, especially the decimal value given for the current date, as this has resolution up to at least the seconds value, yet is clearly quickly outdated. Is there a way to force wikipedia to update this on every view? Otherwise these values should be replaced with something like an examples section, as it is misleading at the moment. 176.248.52.108 (talk) 19:49, 30 December 2012 (UTC)

Perhaps it would be better to have "The Julian Date for [dd mmmm yyyy hh:mm:ss.s] is" instead of "The current Julian Date is" (to an appropriate number of decimal places for seconds and Julian Date)? Particularly as even if the page is updated on each view, that does not mean that that will be the only time the page is looked at! Robertm25 (talk) 12:56, 20 January 2013 (UTC)

Julian day number to Gregorian algorithm

User:173.62.205.220, changed a number in the algorithm. I feel it is too much of a burden for other editors who want to figure out who is right to implement the algorithm, compare it to a known-good source, and decide if the change is correct. Therefore I replaced the algorithm with a copy from a reliable source, the Calenders chapter in the 3rd edition of Explanatory Supplement to the Astronomical Almanac.

In an effort to see if I copied it correctly, I wrote a draft in my sandbox, then implemented the draft in C++. I converted the resulting day, month, and year back to a Julian date with SOFA (astronomy), added 0.5 for the SOFA JD because the JD starts at noon, and tested that the SOFA JD + 0.5 equaled the starting JD. I found the algorithm worked from JD -1363 to at least JD 5,000,000 (that is, 1 March -4716 to at least 7 June 8977). I did not figure out whether it was the Richards algorithm or the SOFA algorithm which failed before 1 March -4716. Jc3s5h (talk) 18:57, 13 March 2013 (UTC)

Lotus Modified Julian Date

The source cited does not support the detail of the date format described in the text. The cited source says:

"Notes stores time and date information in one consistent way on all Notes/Domino computers. It defines a TIMEDATE structure and stores within it both absolute time and date values — that is, a time value represented as standard Greenwich Mean Time (GMT) and a date value represented as a Julian date — as well as some locale-specific time and date values — for example, the time zone of the computer that creates the TIMEDATE structure."

The bit length of the format and the noon epoch are not mentioned on the cited page.

As a second minor point, it appears that the date in the text should read "January 1, 4713 BC", although lacking supporting evidence I haven't changed it.

Finally, it appears that this is merely a binary representation of an integer Julian date (midnight epoch) concatenated with a binary GMT. This should be clarified and I'm not certain whether such a minor variant is worthy of mention. SteveMcCluskey (talk) 16:01, 18 June 2013 (UTC)

I can find nothing in the Lotus source to suggest that Lotus intends Lotus Notes to have any awareness of anything called a (Lotus) Modified Julian Date, nor is there anything to suggest Lotus Notes users have started paying attention to such a date. So I don't think such a thing, if it existed, merits space in the article.

I also don't think the document supports the existence of a (Lotus) Modified Julian Date. There is a mention of Julian date on page 15, but the meaning is unclear. I find the document to be very poorly written, and have no confidence the writer is correct in the statement about Julian date. There is no mention of the Julian date, whatever the writer means by "Julian date", has been modified. Thus I removed the change from the article. Jc3s5h (talk) 23:21, 18 June 2013 (UTC)

Documentation that refers to Julian Day, in which it is clear that they are simply referring to the regular version, not claiming it as their own, and not renaming it as "modified" anything, although they do count from midnight.

Speaking of "variant", I think that "Variants" may actually be a better title than "Alternatives" for this section, or maybe "Variations". --Nike (talk) 07:12, 19 June 2013 (UTC)

==

Math error in Julian Day example

This is in respect of the text "The Julian Date for 00:32, 15 August 2013 (UTC) is 2456519.5228472" in the article. The Julian Date for 00:32, 15 August 2013 (UTC) is 2456519.5222222. The Julian Date for 00:32:54, 15 August 2013 (UTC) is 2456519.5228472. 77.89.154.66 (talk) 15:49, 15 August 2013 (UTC)

That passage used system calls to try to display the current date. But the calls displayed with incompatible precision. I changed it to a fixed example and provided a source. Jc3s5h (talk) 17:27, 15 August 2013 (UTC)

i used the calulator you cited (USNO) and entered 2013 January 1 00:32:00.0 UT. It returned "JD 2456293.522222"; which I agree with. I don't agree with the article figure of 2456293.520833 which appears to be the JD for 2013 January 1 00:30:00.0 UT77.89.154.66 (talk) 09:37, 21 August 2013 (UTC)

I fixed it. Jc3s5h (talk) 10:04, 21 August 2013 (UTC)

Microsoft Access Dates

It looks like Microsoft Access may use Dublin JDN: "Access stores the Date/Time data type as a double-precision, floating-point number up to 15 decimal places. The integer part of the double-precision number represents the date. The decimal portion represents the time. Valid date values range from -657,434 (January 1, 100 A.D.) to 2,958,465 (December 31, 9999 A.D.). A date value of 0 represents December 30, 1899." http://support.microsoft.com/kb/210276 So, 1 would be December 31, 1899 and January 1, 1900 would be 2; which would seem to be a close match to Dublin. Jim.Callahan,Orlando (talk) 20:08, 19 September 2013 (UTC)

Archiving

I notice that automatic archiving is not in operation, but it appears it was in the past. Is there any objection to me restoring it using User:MiszaBot? Jc3s5h (talk) 23:41, 19 September 2013 (UTC)

Done. Jc3s5h (talk) 13:22, 21 September 2013 (UTC)

Contradiction in Correlations

Roman Era is 753bc April 21. The Roman indiction of year 1 in Julian Day thus from 4713bc Jan 1 is 753bc Jan 1 beginning the year before Rome (excused, I can comprehend this). The lunar calendar of 19-year however is 1442bc to 644bc to 625bc if Babylon, and if Jewish 1443bc to 645bc to 626bc and verified by the fact they regard Adam as created with that 1st year 3761bc (2318 years of 122x 19). However, Scaliger's 4713bc precedes this by 952 years of which 50x 19 is 950 with Scaliger's 19-year lunar cycle having its first year in 3763bc (perhaps this might be why Jewish culture tries to proclaim a 3763bc Adam; but then this proves Scaliger was inclined to Jews using a cycle 2 years before the common one claimed. Correlation from Jewish 3761bc is absent new moon 40AD Jan 2 & Sep 24, or 268AD Jan 1 & Sep 23, versus Scaliger 2 years earlier from 4713bc as 38AD to 342AD Jan 23 & Sep 16. Even staying true to 19 years will produce a Jan 1 of 1579AD whose former Jan 2 absent moon in 40AD has retreated to Dec 28 to produce a 1579AD Jan 1 crescent. Someone try to tell me what 19-year calendar, whose 19-year calendar, did Scaliger use.98.144.71.174 (talk) 18:27, 9 November 2013 (UTC)

He was using the golden number, the same as the Catholic Church. 4713 BCE has a golden number of 1. You can read the details in Scaliger's book, just google Opus de Emendatione Temporum. --Nike (talk) 22:33, 9 November 2013 (UTC)

Microsoft Excel DateValue()

"Excel stores dates as sequential serial numbers so that they can be used in calculations. By default, January 1, 1900 is serial number 1, and January 1, 2008 is serial number 39448 because it is 39,447 days after January 1, 1900." This is almost Dublin (off by 1 day according to comparison of Wikipedia table to Microsoft Excel). http://office.microsoft.com/en-us/excel-help/datevalue-function-HP010342404.aspx Jim.Callahan,Orlando (talk) 19:07, 19 September 2013 (UTC) Comparison for September 19, 2013 at 3:10 PM ET MS Excel = 41,536 Dublin JD = 41,535 (Wikipedia table) Jim.Callahan,Orlando (talk) 19:14, 19 September 2013 (UTC)

They are indeed similar, but not the same. Excel serial dates are inherited from Lotus 1-2-3, which set day 1 as January 1, 1900, and also begin at midnight local time, whereas Julian dates start at noon UT, so Dublin date 1.0 was noon UT on January 1, 1900. However, day 60 was rendered as February 29, which did not exist in year 1900, so this is how Excel numbers are converted to dates, compared with Dublin dates (after noon UT):

Number	Excel Date	Dublin Date
0	Invalid Date	December 31, 1899
1	January 01, 1900	January 01, 1900
59	February 28, 1900	February 28, 1900
60	February 29, 1900	March 01, 1900
61	March 01, 1900	March 02, 1900

I believe that Access adds 1 for the first two months of 1900 (so February 28 is 60) and also allows non-positive numbers to store dates before 1900. --Nike (talk) 23:29, 9 November 2013 (UTC)

Variants table precision.

The title in the table gives HH:MM dmy formatting, while the JD calculation shows its full precision. A user (like me) might assume from the given precision that the time heading is HH:MM:00; but its not; its just whatever the {datetime} macro spits out. This threw me for a bit wondering why my implementation of the formulas was not matching, even though double has sufficient precision.

Is it possible to force the {datetime} macro to show the seconds?

Not a wiki-genius myself, so I didn't want to mess with anything; but if it can't, maybe include a little note indicate that "06:35" could be anything from "06:35:00" to "06:35:59"... — Preceding unsigned comment added by 207.70.160.29 (talk) 23:14, 25 November 2013 (UTC)

Range of dates for Gregorian Calendar from Julian Day

The article currently states that the author does not specify date for which the algorithm is valid. I went ahead and checked if there were any limits to the algorithm, basically converting from Gregorian calendar to Julian Day back to Gregorian and seeing if there was any point at which the input no longer matched the output. The algorithm is valid at least up to the year 10000 and down to -6000, so it is logical that the algorithm is valid over all Gregorian dates, especially since the Gregorian calendar runs on a 400 year cycle, and both of these years are far outside of the current cycle. I made the edit to the article but it has since been reverted due to lack of citation.

This leads me to a question I have been wondering about since joining Wikipedia: Are citations required for claims that can be verified mathematically by readers using equations presented in the article?

Jaxcp3 (talk) 02:33, 13 February 2014 (UTC)

I have recently obtained Richard's book Mapping Time: The Calendar and its History, which describes the algorithm in greater detail. I have only skimmed the chapters that describe the algorithm, but it appears it may only be intended to be valid for positive Julian day numbers. Richards states he tested the algorithm from the epoch of each calendar (year 1, month 1, day 1) for 1000 years by finding the JDN from the date, and then converting from the JDN to the date. He considered this check insufficient by itself, so he also spot-checked published values, and compared to other algorithms that he considered reliable. I hope to have a chance to check this more carefully in between shoveling snow. Jc3s5h (talk) 04:52, 13 February 2014 (UTC)

In reading Richard's Mapping Time I find the method for converting a Gregorian day, month, and year is equivalent to the algorithm in Explanatory Supplement to the Astronomical Almanac 3rd ed., although the computations distributed a little differently. The procedure is to change the JDN to a computational calendar date that can be converted to a year Y', Month M', and day D' using the Julian calendar procedure, and then apply correction factors to find the Gregorian year Y, month M, and day D. On page 313 Richards states 0 <= Y'.

Looking in an archive of this talk page, Talk:Julian day/Archive 3#Julian day number to Gregorian algorithm, I see I examined this question previously, and found that one of two algorithms, Richards or Standards of Fundamental Astronomy, failed for JDN -1362 and earlier. I don't know which of the two was wrong. Jc3s5h (talk) 03:04, 14 February 2014 (UTC)

Error example: The Richard's algorithm agrees with the converter at https://www.fourmilab.ch/documents/calendar/ and the Standards of Fundamental Astronomy for JDN -1362, which is March 2, -4716 Gregorian. Keeping in mind that -4716 was a leap year, it is evident that February 1, -4716 should be JDN -1392. But when -1392 is entered into the algorithm, the output year is wrong by a year; the output is -4715. Jc3s5h (talk) 03:21, 14 February 2014 (UTC)

Where the day started

If I am not mistaken, Scaliger referenced the start of the day to Alexandria. At some later point - late 19th century - it was moved from wherever it was at the time, to London, reflecting 0 degrees of longitude that passed through the place. I believe this has been the only change made to the system since it was started.

For casual readers it would help if noon and midnight starts were made more explicit.

It would also help to realize that noon was not only the start of the astronomical day, but until rather recently, was the start of the legal day as well. As we can see in the US Constitution, where Presidents have always taken office at noon on the day. Never midnight. Wiki should have an article on the Legal Day, as many people are confused on this point. — Preceding unsigned comment added by 108.15.102.104 (talk) 18:32, 19 May 2014 (UTC)

Vandalism

remove this after ... a month as passed please.

I submitted the below (two separately) and both were deleted with excuse "is not HTML (java.js)". absolute trash. i wouldn't use either for equations unless paid to. there is no rule that a science Link must lead to an HTML - and many do NOT.

Months` has free equations for moving between gregorian, julian, julian day, gregorian day, and more all directions. It is simple: ie, if one marks a ruler every 365 units and observes the sun's progress on, then every 4 years is a leap due to a full day of difference between markings and actual. Predicting number of leapdays is not a challenge for Gregorian or Julian. In moving between calendars Epoch is also considered.

• Months` free equations: Julian <> Gregorian <> jdn <> gdn <> Epoch[JDN] <> Epoch[2000], Julian Century, synodic, anomalistic, more fully arbitrary precision.

(the above has big-O of zero for distant dates and is arbitrary prec., many other Links break those two rules. meaning: there is a point to using it rather than the other choices presented)

Navstar55 (talk) 14:45, 14 July 2014 (UTC)

Read WP:ELNO. Links to personal web pages are unwelcome. If you are the only one working on the sourceforge project, you should not link to it. Wikipedia relies on information that has been published in reliable sources. Original research is not allowed. Jc3s5h (talk) 14:57, 14 July 2014 (UTC)

What is "Julian day"?

I modified the sentence defining Julian Day Number to say "the integer assigned to a day according to the Julian day count, with Julian day number 0 assigned to January 1, 4713 BC" instead of "the integer assigned to a whole solar day in the Julian day count starting from noon Greenwich Mean Time, with Julian day number 0 assigned to the day starting at noon on January 1, 4713 BC". User:Jc3s5h reverted this, with the comment "Even though JDN is an integer and applies to a whole day, it is vital to say when the day begins." But is it really defined that way? I looked at the corresponding article in other languages, and they don't say that. And this English article, in the section on calculating the Julian day from a given Gregorian date, says nothing about it being different before midday and after midday. Of course, the "Julian date", which is a sort of "real number", becomes an integer at midday GMT, but is the Julian day defined as the "floor" of the Julian date for a given precise moment, or simply as a number which is a function of the date (whether a Gregorian date or a date in some other calendar)? Even the present version of this article says "For example, the Julian day number for January 1, 2000, was 2,451,545" (with reference), as though that was the Julian day number for the whole day, not just for the afternoon of that day. Eric Kvaalen (talk) 13:06, 15 September 2014 (UTC)

Of course the article should be read as a whole, so a definition from one section applies in other sections unless it is clearly stated the definition is confined to a particular section. That is why Eric Kvaalen's change ruins the whole article. Here are definitions from a reliable source, the glossary of Explanatory Supplement to the Astronomical Almanac 3rd Ed. by Sean E. Urban and P. Kenneth Seidelmann, published by University Science Books in 2013.

Julian date (JD): the interval of time in days and fractions of a day, since 4713 B.C. January 1, Greenwich noon, Julian proleptic calendar. In precise work, the timescale, e.g., Terrestrial Time (TT) or Universal Time (UT), should be specified.

Julian day number: the integral part of the Julian date (JD).

The italics in the quotations indicate terms that have definitions within the glossary.

Since the Julian day number is the integral part of the Julian date, and the Julian date begins at Greenwich noon, it follows that the Julian Day Number begins at Greenwich noon. — Preceding unsigned comment added by Jc3s5h (talk • contribs) 13:22, 15 September 2014 (UTC)

The Julian day was defined as starting at noon by Herschel in 1849, as the article already quotes. The inventor of the term is a pretty authoritative source, and it has been used that way ever since, with the one change being that the time zone (in modern terms) was changed from Alexandrian time to GMT. Julian days began at noon even before astronomers added fractions to make Julian Dates. Before the 1920s, calendar dates, e.g. April 19, also were reckoned from noon by astronomers. There was actually a debate at the time, and it was agreed that the origin of the Julian day is an important part of the definition. --Nike (talk) 20:11, 19 April 2015 (UTC), JD 2457132.341

Poor date choice

In this edit User:Nike changes an example of a Julian date, in the sense of a date of the Julian calender. The date before Nike's change, May 12, 1629, the date of the Treaty of Lübeck, was a fairly good date because some of the parties to the treaty used the Julian calendar, and some used the Gregorian calender, so there would be no way to guess which calendar May 12, 1629 was in unless it was explicitly stated. The only bad part about the choice is that most English-language readers won't be familiar with the treaty; a date that is well-known by a larger proportion of readers to involve both Gregorian users and Julian users would be better. But the date that was changed to, October 5, 1582, was before the introduction of the Gregorian calendar anywhere, so it would not be normal to specify that it was Julian calendar date. Jc3s5h (talk) 20:39, 19 April 2015 (UTC)

The Proleptic Gregorian calendar (before it was introduced) is not too unusual, also see ISO 8601. An "ideal" switch from Julian to Gregorian would be from 1 March 200 to 28 February 300, the century where both calendars yield the same dates as explained on Proleptic Gregorian calendar. If I understand your objection correctly you want a "non-proleptic" date, and the first is apparently 5 October 1582 Gregorian + 25 September 1582 Julian. Six days later might be easier to see: 11 October vs. 1 October. Some interesting historical date, when the differences were important (your idea), is not bad, but it might be not simple enough for folks only wanting to know what this is about. IOW, I don't really care if it's guaranteed to be correct, and that's not obvious for 1629: Shouldn't the difference be 11 days at this time? –Be..anyone (talk) 00:32, 20 April 2015 (UTC)

Most of the use of the proleptic Gregorian Calendar I've noticed was defining various epochs for things such as computer operating systems or date conversion software. But these systems are mostly used for fairly recent dates, or to store intermediate results during a computation. I think it's pretty unusual to encounter a proleptic Gregorian date in prose.

The 10 day difference is correct. That was the difference at the introduction of the Gregorian calendar. Since 1600 was evenly divisible by 400, 1600 was a leap year in both calendars, so the difference did not change until 1700. Also, I checked the date with the Gnu Emacs calendar, originally written by Edward Reingold. Jc3s5h (talk) 01:55, 20 April 2015 (UTC)

Since the Julian calendar remained in use centuries after the Gregorian calendar was introduced, there are many such dates. George Washington's birthday is often shown in both calendars, since both were used in the English colonies during his lifetime. The October Revolution happened in November, 1917, in the Gregorian calendar. Why pick that particular date? It is irrelevant to the article.

October 5, 1582, was not before the introduction of the Gregorian calendar, but very first day it was used, according to the Julian calendar, thus the first day known by different dates in the two calendars. It was known as October 15 in the Gregorian. It was also the period when Salinger was working on his book which named the Julian Period. --Nike (talk) 02:37, 20 April 2015 (UTC), JD 2457132.609

Sounds like a bug on Proleptic Gregorian calendar, where the table ends with September 24 instead of October 4. –Be..anyone (talk) 02:51, 20 April 2015 (UTC)

I don't know why that is. October 4, 1582, was the last day the Julian calendar was used in most Catholic countries. It was followed by October 15 in the Gregorian. --Nike (talk) 03:07, 20 April 2015 (UTC)

Added long passage not very useful

The long passage added in this edit is not very useful. It doesn't give a method to calculate the year of the Julian period from the CE or BCE year; it just gives a test to see if one has guessed the right answer or not. If that amount of space is going to be devoted to the issue, it would be better to find an algorithm in a reliable source and put it in the algorithms section. Jc3s5h (talk) 14:28, 20 April 2015 (UTC)

Obviously I agree, the same already reverted off topic calculation added and reverted again, but now separated from lots of good redundant link removals, lower case calendar, etc. –Be..anyone (talk) 19:39, 20 April 2015 (UTC)

Lead doesn't give the information people come here for

The lead of this article could do a better job of giving the searched information by people who come to this page. I'd imagine one of the first question people ask about the Julian day is: "Ok so it's counting days from January 1, 4713 BC. Why January 1, 4713 BC as a starting point?" PizzaMan (♨♨) 10:27, 19 April 2015 (UTC)

I added a reason to the history section (with citation); Scaliger thought 4713 BC would be before any historical record. If that's the reason you're looking for, you could add it to the lead. If you are thinking of the three cycles Scaliger used (solar cycle, golden number and Indiction) I think that's rather complicated and the lead is already too long to accommodate that explanation. Jc3s5h (talk) 11:34, 19 April 2015 (UTC)

I think the reason 4713 was taken as a starting point is more relevant to the average person visiting this page than half the info that's currently in the lead. And i think it's hard to explain why exactly 4713BC without going into the three cycles briefly. PizzaMan (♨♨) 10:38, 22 April 2015 (UTC)

Timestamp column

Hi, the timestamp column for the begin of the epochs is rather messy, normal YYYY-MM-DD HH:MM timestamps in a monospaced font as explained in MOS:DATEFORMAT (fifth row) would be far clearer. However, here this would require one case of -YYYY-MM-DD HH:MM, killing the effort with one very unclear and very unusual "negative" year better explained in prose.

Therefore the column uses 12h or 0h, followed by abbreviated month mmm, numeric day, comma, numeric year, BC meaning BC or BCE where needed, and depending on which version of the page you look at something best described as "random garbage", e.g., an unexplained (1) meaning "epoch counts days from one" (now footnotes), or "Gregorian calendar" for what is actually "ISO 8601 0001-01-01 in the proleptic Gregorian calendar".

This wrong annotation is unnecessary, the details are explained in prose below the table, and the wikilinked Rata Die also explains it. The reference in the last column of this row is a bad idea for the layout (the table is already rather wide), it should be in the Rata Die prose, or not mentioned here, because the wikilinked article already has it.

What still is missing is a link to ISO 8601 to explain the 0001-01-01 business given as "Jan 1, 1". Therefore I tried a clearer [[ISO 8601|Jan 1, 0001]], rendered as Jan 1, 0001 and matching the mmm DD, YYYY style in all other rows. The old version "0h Jan 1, 1 (1)" was IMO gibberish. But so far that intended improvement was reverted twice by Jc3s5h, who claims that MOS:DATEFORMAT forbids 0001, while I think that it is consistent per MOS:DATEUNIFY in this table. FWIW it is not shown as MOS:BADDATEFORMAT. The three MOS shortcuts are neighbours on the same MOS page.

IMO it's also notable (= not obvious) that all ISO 8601 dates yyyy-mm-dd in the Common Era (after year 0) can be expressed as positive whole day number in the Rata Die epoch, and just wikilinking ISO 8601 would cover this detail. A "no-nonsense" subset of ISO 8601 was published as RFC 3339, and is used in various Internet protocols including W3C formats (HTML, XML) needing a timestamp format, right down to PHP and Mediawiki (the stuff that makes Wikipedia tick, pun intended.) –Be..anyone (talk) 20:22, 24 April 2015 (UTC)

I will repeat Be..anyone's comment with my responses added.

'Hi, the timestamp column for the begin of the epochs is rather messy, normal YYYY-MM-DD HH:MM timestamps in a monospaced font as explained in MOS:DATEFORMAT (fifth row) would be far clearer. However, here this would require one case of -YYYY-MM-DD HH:MM, killing the effort with one very unclear and very unusual "negative" year better explained in prose.'

Since elsewhere Be..anyone mentions ISO 8601, Be..anyone apparently associates the YYYY-MM-DD format with that standard. But that standard requires that it only be used with the (possibly proleptic) Gregorian calendar, so that leaves out Jan 1, 4713 BC, because that's a proleptic Julian calendar date. Further, ISO 8601 requires agreement among data exchange partners to use it for any date before 1583; our data exchange partners are our readers, and Be..anyone has not demonstrated that our readers have consented.

'Therefore the column uses 12h or 0h, followed by abbreviated month mmm, numeric day, comma, numeric year, BC meaning BC or BCE where needed, and depending on which version of the page you look at something best described as "random garbage", e.g., an unexplained (1) meaning "epoch counts days from one" (now footnotes), or "Gregorian calendar" for what is actually "ISO 8601 0001-01-01 in the proleptic Gregorian calendar".'

"Epoch counts days from one" isn't terribly clear; now that it's in a footnote, maybe it can be expanded a little to make it clear. As for labeling it Gregorian, it would be better if it said proleptic Gregorian calendar. But the current version, that just says Jan 1, 0001, is flat out wrong. First, it isn't an ISO 8601 date because the month is expressed in letters rather than numerals, so a person who follows the link won't know what to think of it. Second, if the article is printed, the reader can't follow the link, so for that reader the date is absolutely false, because the custom for dates around that time is to express them in the Julian calendar unless otherwise stated. Finally, it is improper English to write years with leading zeros.

'This wrong annotation is unnecessary, the details are explained in prose below the table, and the wikilinked Rata Die also explains it. The reference in the last column of this row is a bad idea for the layout (the table is already rather wide), it should be in the Rata Die prose, or not mentioned here, because the wikilinked article already has it.'

I don't object to moving the citation to the prose. Each article stands alone as far as citations go, so the citation must be in this article, not a wikilinked article. Also, a statement that the epoch of Rata Die is January 1, 1, is false unless it is also stated, in the immediate vicinity of the date, that it is a (proleptic) Gregorian calendar date. In another article, I wouldn't insist on saying "proleptic", but since the word is applied in several other spots in the article, we should be consistent.

'What still is missing is a link to ISO 8601 to explain the 0001-01-01 business given as "Jan 1, 1". Therefore I tried a clearer [[ISO 8601|Jan 1, 0001]], rendered as Jan 1, 0001 and matching the mmm DD, YYYY style in all other rows. The old version "0h Jan 1, 1 (1)" was IMO gibberish. But so far that intended improvement was reverted twice by Jc3s5h, who claims that MOS:DATEFORMAT forbids 0001, while I think that it is consistent per MOS:DATEUNIFY in this table. FWIW it is not shown as MOS:BADDATEFORMAT. The three MOS shortcuts are neighbours on the same MOS page.'

I argue that since other dates in the article are written in the customary American format, inventing a format just for this article that has leading zeros for the year is contrary to MOS:DATEUNIFY. Also, ISO 8601 has nothing to do with it; it doesn't apply to dates with the month expressed in letters rather than numerals, and the proleptic Gregorian calendar existed for centuries before ISO.

'IMO it's also notable (= not obvious) that all ISO 8601 dates yyyy-mm-dd in the Common Era (after year 0) can be expressed as positive whole day number in the Rata Die epoch, and just wikilinking ISO 8601 would cover this detail. A "no-nonsense" subset of ISO 8601 was published as RFC 3339, and is used in various Internet protocols including W3C formats (HTML, XML) needing a timestamp format, right down to PHP and Mediawiki (the stuff that makes Wikipedia tick, pun intended.)'

Days in the Common Era can be expressed as a positive number in the Rata Die epoch, more or less, whether ISO 8601 had ever been written or not. The more or less part is because dates of that time are usually written in the proleptic Julian calendar; proleptic Julian January 1 and 2, AD 1, are Rata Die 0 and −1, respectively. RFC 3339 has never been accepted for use in Wikipedia articles. Also, it forbids Julian dates and negative years (or BC years). Since this article requires BC years and Julian dates, MOS:DATEUNIFY requires that the whole article should use a date format capable of expressing such dates. Jc3s5h (talk) 21:32, 24 April 2015 (UTC)

Is the alternative algorithm to derive the date from the Julian day useful?

In https://en.wikipedia.org/w/index.php?title=Julian_day&curid=38007&diff=660180374&oldid=660026501 user Machdohvah added an algorithm from the University of Texas, which seems problematic for these reasons:

• One algorithm is enough.
  • This does also provide hours and minutes, but that is a trivial extension distracting from the harder part of the problem.
• The formatting is inconsistent with the rest of the article.
• It does not provide the Julian date.
• Rather than integer division it uses both floating point and conditional statements, and is therefore presumably somewhat slower.
  • (I don’t suppose it is error prone given the size of the numbers in question.)
• If it is to be considered less desirable, it is unfortunate that it is better suited to cut and paste.

I cleaned things up a bit, but I suspect it should go — what does anyone else think? PJTraill (talk) 08:55, 1 May 2015 (UTC)

I suspect so too. I don't feel it adds anything – and not encyclopedic? If it stays, note that the method conflicts with the rubric for this section (Calculation): "integer division is used exclusively". Wellset (talk) 10:48, 1 May 2015 (UTC)

There's no reason to have a second pseudocode algorithm. There is a plethora of computer languages and and one can write the original algorithm in his language of choice. It should go. Senor Cuete (talk) 13:02, 1 May 2015 (UTC)

The "alternative algorithm" in "C" =

This is "Machdohvah". I was told not to edit the page as I did. I, therefore, deleted the entry. Here is the code: This one works as the other one does not. That is why I wished to include it in the page. To answer questions regarding the use of a long integer is that the number are larger then the scope of an integer. The "long" takes care of that. This is from the University of Texas [ http://quasar.as.utexas.edu/BillInfo/JulianDatesG.html ] and should REPLACE the other algorithm. To answer the comment "It does not provide the Julian date.", it is provided as the head of the function. -- Michael Flower (talk) 23:10, 1 May 2015 (UTC)

char *FromJulianDayHourMin(char *__s,double dJDN) {
    double Q = dJDN+0.5;
    long Z = (int) Q;
    long W = (Z - 1867216.25)/36524.25;
    long X = W/4;
    long A = Z+1+W-X;
    long B = A+1524;
    long C = (B-122.1)/365.25;
    long D = 365.25*C;
    long E = (B-D)/30.6001;
    long F = 30.6001*E;
    int Day = B-D-F+(Q-Z);
    Day--;
    int Month = E-1;
    int Year = C-4716;
    if (Month>12) Month = E-13;
    if (Month<=2) Year++;
    double Mantissa=Q-Z;
    int Hour=Mantissa*24;
    Mantissa=(Mantissa*24)-Hour;
    if (Hour>23) Hour = 23;
    if (Hour<0) Hour = 0;
    int Minute=Mantissa*60;
    if (Minute>59) Minute = 59;
    if (Minute<0) Minute = 0;
    sprintf(__s,"Month=%d, Day=%d, Year=%d, Hour=%d, Min=%d",Month,Day,Year,Hour,Minute);
    return __s;
}

This is also an algorithm in "C" to do the reverse: -- Michael Flower (talk) 23:10, 1 May 2015 (UTC)

double ToJulianDayHourMin(int month1,int day1,int year1,int hour1,int min1) {
    long intRes1;
    long intRes2;
    long intRes3;
    double JDN;
    double jdhmn1;
    if (month1<3) {
        month1 += 12;
        year1--;
    }
    intRes1 = ((2 - year1 / 100) + (year1 / 400));
    intRes2 = (int) (365.25 * year1);
    intRes3 = (int) (30.6001 * (month1 + 1));
    JDN = 1+(intRes1 + intRes2 + intRes3 + day1 + 1720994.5);
    jdhmn1 = JDN + (((double) hour1)/24);
    jdhmn1 += (((double) min1)/1440);
    return jdhmn1;
}

These are NOT algorithms. They're C functions. An algorithm is language agnostic and so is a better choice for the article. Also I should point out that the first function is FUBAR. You passed a pointer to a string to the function. Then you wrote the result of the calculation to the string. Why the !@#$%^& would you also declare the function as returning a char * and return the string? Whoever wrote this is a real amateur. Also why did you put C in Quotes? Senor Cuete (talk) 04:39, 2 May 2015 (UTC)

@Machdohvah:A number of people over the years have come here with posts to the effect "This one works as the other one does not." Usually these people didn't ignore remainders as the beginning of the section instructs. Can you show your work to prove that "the other one does not"? Jc3s5h (talk) 15:51, 8 May 2015 UTC

No, nobody has ever claimed that their code works and that someone else's doesn't, except for you when you "corrected" some posted coded in a way that broke it and then you complained. No, other editors probably won't teach you to program and no, they probably won't do your homework for you. This is probably a bad idea and there are plenty of source code sharing sites like source forge that are there to share code. Wikipedia isn't really for this. Senor Cuete (talk) 18:51, 8 May 2015 (UTC)

Meeus Jean. Astronomical Algorithms (1998), 2nd ed, ISBN 0-943396-61-1 is the bible of doing astronomical calculations. You can buy it from Willman-Bell publishers. One simply can't heap enough praise on Jean Meeus. Go to www.sourceforge.net and search for "Meeus astronomical algorithms". Google something like "Meeus astronomical algorithms source code". Some of the source code you find will be in some obscure language but as I recall, this is in C at source forge. I learned to program in C using "A book on C" by Kelly and Pohl. I highly recommend it. Meeus' algorithm for converting dates to Julian days won't work for negative JDs. An alternate method that will work for JDs < 0 would be the method of Peter Baum, which was on line at one time. Senor Cuete (talk) 19:28, 8 May 2015 (UTC)

My preferred algorithms for conversion are those in Nachum Dershowitz and Edward Reingold's Calendrical Calculations 3rd ed. These were tested over a wide range (I think ± 10,000 years from the present, but I can't find the passage about how it was tested at the moment). However, I don't think it is a good algorithm to put in this article because it is in Lisp, which isn't easy to read. Also, there is no direct algorithm to go from a calendar date to a Julian date; you have to go from calendar to rata die and then from rata die to Julian date. Jc3s5h (talk) 19:54, 8 May 2015 (UTC)

Important point: an algorithm is a method for performing a mathematical calculation, so no computer code in any language is an algorithm. It's an implementation of an algorithm. Also the Methods of Meeus and Baum are direct algorithms that don't use rata die. Senor Cuete (talk) 14:19, 9 May 2015 (UTC)

The Wikipedia article about Jean Meeus contains this link :http://www.naughter.com/aa.html This site has the source code in C++ to implement the methods in Astronomical Algorithms. The code to do the calculations can be used without encapsulating it in objects. Senor Cuete (talk) 16:25, 9 May 2015 (UTC)

This might be helpful: http://sourceforge.net/projects/astroalgorithms/?source=directory Senor Cuete (talk) 17:10, 9 May 2015 (UTC)

What?! I want a food date

Came here to find a quick way to convert a truncated Julian date on a food package. Ha ha! No luck here. 174.100.209.41 (talk) 00:56, 4 October 2015 (UTC)

Incorrect Information re: VMS epoch, etc.

Current article says: " MJD is the epoch of OpenVMS, using 63-bit date/time, postponing the next Y2K campaign to July 31, 31086, 02:48:05.47.[11][citation needed] The MJD has a starting point of midnight on November 17, 1858 and is computed by MJD = JD - 2400000.5 [12]"

Y2K is a topic beyond OpenVMS, and a 64 bit machine using the same MJD schema of 100-nanosecond resolution since midnight of Nov. 17, 1858 can handle 3050056 wks 6 days 5 hrs. 36 mins. 10 secs. 955 ms. 161 us. 500 ns. of information such that the final usable date would be Tue Apr 14, 60314 05:36:10 Am.

The implied meaning of the second sentence is that MJD is the same as the 63-bit unsigned integer as used in OpenVMS. The computation noted is invalid since it is using a floating point number. The correct formula to compute the MJD is to use JDN ( Julian Day Number ) such that MJD = JDN - 2400001. 108.185.212.209 (talk) 17:18, 4 November 2015 (UTC)

First, a reliable source for this information must be provided, in accordance with the Wikipedia verifiability policy. Since you have challenged the information, we are now in the position of either finding a reliable source about OpenVMS, or deleting the information.

Many of the reliable sources already given in the article make it certain that MJD = JD - 2400000.5 The statement by 108.185.212.208 that MJD = JDN - 2400001 is certainly wrong. If some source related to OpenVMS says that, that source is wrong. Jc3s5h (talk) 20:50, 4 November 2015 (UTC)

Copied citation from Epoch (reference date). I have no idea what the IP user was on about, but I did remove the inappropriate reference to Y2K. Arcorann (talk) 03:23, 24 December 2015 (UTC)

table computed from local time-zone? =

Is the table shown on the page computed from local time? If so maybe it should be explicitly mentioned and the input date (iso8601 format) and time which is used for the computation stated? In most fields it is customary to relate MJD only to UTC, not a local timezone. — Preceding unsigned comment added by 130.188.236.217 (talk) 19:48, 21 March 2016 (UTC)

Notice above the table it says "0h is 00:00 midnight, 12h is 12:00 noon, UT unless otherwise specified." UT stands for Universal Time, which is the time at 0° longitude. The first use of UT provides a link to our article about it. I believe the entry for Lillian date used to mention that sometimes it's based on local time. I restored that information.

I have now noticed that there is a tool-tip on the "Current Value" column title. However that refers to a UTC time about 20-25 minutes ago, even when I refresh the page with CTRL-F5 or similar. I suggest the UTC time that the table is based on would be included as a data-row. It's not clear how often the table is refreshed, now it is 20-25 minutes late but can it be 1 hour or more? What is meant by "Current" in this context? — Preceding unsigned comment added by 130.188.45.13 (talk) 09:23, 23 March 2016 (UTC)

Julian day to Gregorian calendar date

For the conversion from Julian day to Gregorian calendar date, Tøndering's calculation[1] also seems simple. I think it is better than Richard's. Kkddkkdd (talk) 14:47, 12 May 2015 (UTC)

Material in Wikipedia should be from reliable sources. Richard is obviously a reliable source. While I personally trust Tøndering's work, it seems to be self published. To meet the exception for experts given in WP:USERGENERATED Tøndering would have to have published in reliable sources in the field of astronomy or calendars; I am not aware of any such publications. Jc3s5h (talk) 17:45, 12 May 2015 (UTC)

The formula is quite obviously right. I would apply the WP:CALC exception. 156.61.250.250 (talk) 08:55, 13 May 2015 (UTC)

Rather than arguing over sources and whether or not calc applies (which i agree it does), let's first ask the question: does anybody even dispute the Tøndering's calculation? I most definitely couldn't find any sources for that, no matter how hard i tried. Pragmatism... PizzaMan (♨♨) 18:52, 11 September 2015 (UTC)

The title of this section says we want an algorithm to convert from Julian day to Gregorian calendar date. But Tondering's algorithm is for the other direction. Tondering's algorithm is the same as already present in the article, and Tondering is credited as the source. Jc3s5h (talk) 19:44, 11 September 2015 (UTC)

Could just be me, but neither Tøndering's nor Richard's calculations work. Julian date is 2457605.749306 and the Coordinated Universal Time is 2016 Aug 5th, 5:58. The day keeps showing up wrong. That said, the javascript in this[2] site does seem to work. I can't make heads or tails of what variables are in any of the calculations, but if anyone other programmers are running into this problem it's worth digging through the javascript on that site. 24.29.75.212 (talk) 06:29, 5 August 2016 (UTC)

I wrote Module:Date using Tøndering's method and checked that it works from 9999 BCE to 9999 CE. The following template uses the module to display your Julian date in a default format:

• {{extract|juliandate|2457605.749306}} → 05:59 5 August 2016

Johnuniq (talk) 08:49, 5 August 2016 (UTC)

When people have trouble getting these algorithms to work, it usually turns out to either be failing to notice that the divisions are integer divisions, or problems with the way modulo arithmetic is done with negative numbers. Jc3s5h (talk) 12:07, 5 August 2016 (UTC)

Formatting issue

I see an issue in the fourth paragraph. The Wiki markup "{{currentyear}} is year {{#expr: {{currentyear}} + 4713 }}" gives me "2016 }} is year Expression error: Unrecognized punctuation character "}". ". Unfortunately I don't know enough about mediawiki markup to fix it. 197.88.33.244 (talk) 16:54, 14 August 2016 (UTC)

Template:Currentyear

@Jc3s5h: Re your edit, I fixed {{Currentyear}} which was recently edited in a way that broke it. However, that template points out that the magic word should be used, not the template. That is, {{CURRENTYEAR}} should be used, nor {{currentyear}}. I think your fixed text showing 2016 is simple and good, but if wanted, you could put it back using CURRENTYEAR. Johnuniq (talk) 02:06, 15 August 2016 (UTC)

Year Numbering in Julian Period

Please clarify how the year numbering in a Julian Period works. Is 4713 BC the 1st or 0th year of the current Julian Period? — Preceding unsigned comment added by 49.213.19.179 (talk) 17:54, 27 December 2016 (UTC)

According to page B5 of the Astronomical Almanac for the year 2017 (US Naval Observatory and H. M. Nautical Almanac Office) the year 2017 is year 6730 of the Julian period. Subtracting 6730 from 2017 gives -4713, which is the same as 4714 BC, and corresponds to year 0 of the Julian period, so 4713 would be year 1 of the Julian period. Jc3s5h (talk) 18:28, 27 December 2016 (UTC)

I have edited the article to clarify this point. Jc3s5h (talk) 02:57, 28 December 2016 (UTC)

No, you are mistaken. JD 0.0 = noon on January first -4712 or 4713 BC. -4712 is year zero, not one of the Julian period. Senor Cuete (talk) 20:42, 1 January 2017 (UTC)

The Julian period devised by Joseph Justus Scaliger in the 16th century; it is a way of naming years. The Julian day evolved from the Julian period; it was explained by John Herschel in 1849. Another quote to support the claim in the article, from page 592 of Richards:

Scaliger could, therefore, characterize a year by a triplet of numbers (S, G, I); S, the number of the year in the solar cycle, runs from 1 to 28; G, the number of the golden year, runs from 1 to 19, I, the number of the year in the Indiction cycle runs from 1 to 15. This he called a Julian period, because it was based on the Julian calendar year. For his initial epoch, Scaliger chose the year in which S, G and I were all equal to 1. He knew the year 1 (A.D. 1) had S = 10, G = 2 and I = 4 and worked out that the combination (1,1,1) occurred in the year −4712 (4713 B.C.) which was year 1 of Scaliger's Julian period.

Jc3s5h (talk)

References

• Richards, E. G. (2013). Calendars. In S. E. Urban & P. K. Seidelmann, eds. Explanatory Supplement to the Astronomical Almanac, 3rd ed. (pp. 585–624). Mill Valley, Calif.: University Science Books. ISBN 978-1-89138-985-6

That's right, but the first year of this system is the year zero. It's not the year one until the first year is completed. Senor Cuete (talk) 22:39, 1 January 2017 (UTC)

Asserting something is so does not make it so. You need to show evidence that overrides that which has already been given. Try reading the original source by Scaliger, or Herschel. Astronomical year numbering was introduced centuries after the Julian Period was, and has never been used for years of the Julian Period. Just as the first year of the Common Era (AD) was the year 1, and the 2017th year is 2017 CE/AD, the first year of the Julian Period is numbered as 1. --Nike (talk) 01:31, 2 January 2017 (UTC)

Get your astronomical algorithms book, program your computer to do this and convert JD = o.o to a date. Senor Cuete (talk) 02:02, 2 January 2017 (UTC)

I have actually written a number of JD conversion programs over the past several decades, and they all indicate that JD 0.0 occurs in the year 1 of the Julian Period. Any book stating otherwise is in contradiction of the primary sources, but I have not encountered such an erroneous book. You have failed to provide any sources which back up your claim. I gave you two: Scaliger's Opus de Emendatione Temporum and Herschel's Outlines of Astronomy. The first is the primary source for the Julian Period, and the second is the primary source for Julian days. --Nike (talk) 04:15, 2 January 2017 (UTC)

A Julian date (JD) is a number which identifies a particular instant of time. JD 0.0 was at noon UTC on 24 November 4714 BCE (−4713, 11, 24) in the Gregorian calendar. The year starting at that date/time was the first year of the current Julian period, but whether that year should be called year 0 or year 1 is a semantic preference. The recently edited text in the article includes:

The Gregorian year 2024 is year 6737 of the current Julian Period.

Editing the text shows that it is a calculation: Y is year (Y + 4713) of the current Julian Period, where Y = year in the Gregorian calendar. Applying that calculation to the start date (24 November 4714 BCE) requires expressing 4714 BCE as −4713 then adding 4713. The result is 0, but it would still be reasonable for someone to refer to that as being the first year.

Wikipedia is not a reliable source, but as a matter of interest there is a template which can extract and show dates, examples:

• {{extract|juliandate|0.0|show=dmy hm}} → 24 November 4714 BC 12:00
• {{extract|12:00 1 January 2017|show=juliandate}} → 2457755

Johnuniq (talk) 06:51, 2 January 2017 (UTC)

It is not a semantic preference. The numbering of years in the Julian Period is a convention which has been established for more than four centuries. The first year of the Julian Period was always enumerated as year 1. What some template shows is irrelevant. Calling the first year "0" would change the value of the current year, as well as that of every written reference for the past 434 years. 2017 CE is year 6730 of the Julian Period. --Nike (talk) 09:12, 2 January 2017 (UTC)

I forget what we're arguing about now, but the rule I gave above [Y is year (Y + 4713)] is correct, and it refers to the Gregorian calendar (diff is not correct). We agree that this year is 2017 CE (Gregorian calendar) which is year 6730 in the current Julian Period because 2017 + 4713 = 6730. That is, add 4713 to the Gregorian year to get the year in the Julian Period. Year 0 in the Julian Period is therefore year −4713 in the Gregorian calendar, which is 4714 BCE Gregorian. Johnuniq (talk) 09:58, 2 January 2017 (UTC)

You are referring to a template, which is not an authoritative source of anything. Years of the Julian Period are always Julian calendar years. It is currently still 2016 AD in the Julian calendar, which is 6729 J.P. However, it is strictly correct to state that 2017 is 6730 J.P. in the Julian calendar because it is not claimed to be the current year, which ends in a few days. --Nike (talk) 17:01, 2 January 2017 (UTC)

I don't read Latin, so have not read De emendatione temporum (1583), but from what I've read in other sources, this is what sets out the Julian period. We can guess that the Julian period applied, at least implicitly, to the Julian calendar, since Scaliger was an historian and the Gregorian calendar came into force in the same year the book was published, so everything Scaliger wrote about would have occurred under the Julian calendar (or other earlier calendars). But in The Astronomical Almanac for the year 2017 page B4 we see

        CHRONOLOGICAL CYCLES AND ERAS
        ...Julian Period (year of) ... ... ... 6730
        .
        .
        .
        All dates are given in terms of the Gregorian calendar in which
        2017 January 14 corresponds to 2017 January 1 of the Julian calendar
        ERA                  YEAR       BEGINS
        Byzantine             7526       Sept. 14....

Since the Astronomical Almanac does not provide a starting date for the year of the Julian Period, I infer that it can be considered to coincide with the Gregorian calendar year in 2017. Alternatively, maybe it is like "2017" itself; perhaps it can be used to label years in either the Julian or Gregorian calendars. I think we would need a source that addresses the point more directly to decide. Jc3s5h (talk) 15:53, 2 January 2017 (UTC)

It is not necessary to translate (although there are online tools which will do that) because the article already gives the relevant passage: "We have called it Julian merely because it is accommodated to the Julian year." See also Herschel, for instance, "The Julian rule made every fourth year, without exception, a bissextile, beginning with the year J.P. 1, which is to be accounted as such." (emphasis in original) --Nike (talk) 16:49, 2 January 2017 (UTC)

I'm willing to accept Herschel's interpretation, since he was writing well after the Gregorian calendar was in widespread use, including in his own country of Britain. I'm glad we don't have to rely on Scaliger, since the Gregorian calendar was in its infancy in Scaliger's time. I'll remove the disputed tag from the article. Jc3s5h (talk) 19:35, 2 January 2017 (UTC)

For the record, I see that my above comments were incorrect as I was misled by Gregorian/Julian confusion. The correct situation is:

Year Y in the Julian calendar is year (Y + 4713) of the current Julian Period.

1 January 4713 BCE (year −4712) in the Julian calendar is the start of year 1 of the Julian Period.

I mentioned {{extract}} for anyone interested and explicity said it is not a reliable source. However, it can show Julian dates:

• {{extract|juliandate|0.0|julian}} → 12:00 1 January 4713 BC (Julian calendar)
• {{extract|juliandate|0.0}} → 12:00 24 November 4714 BC (Gregorian calendar)

Johnuniq (talk) 01:08, 3 January 2017 (UTC)

Oddly, I cannot find the exact quote in Scaliger, Iulianum vocauimus: quia ad annum Iulianum dumtaxat accomodata est. This quote was introduced in a very early version of the article. I found one very similar on page 361, however:

Iulianam vocauimus, quia ad annum Iulianum accommodata

Also from page 22:

periodi huius, quam Iulianam vocamus, quod ad Iulianam anni formam accommodata sit.

--Nike (talk) 06:42, 3 January 2017 (UTC)

Found it. Apparently I was using a later edition, from 1629, which differs from a 1593 edition which has the exact quote. --Nike (talk) 17:20, 3 January 2017 (UTC)

Java Month Pitfall

Java's Calendar class returns month values in the range 0-11 instead of 1-12. So, if you use Java, be sure to add 1 to the month in order to get the correct JD. Hope this helps someone avoid my mistake! 70.190.166.108 (talk) 00:32, 20 February 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Julian day. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20080712061305/http://emr.cs.iit.edu/home/reingold/calendar-book/third-edition/ to http://emr.cs.iit.edu/home/reingold/calendar-book/third-edition/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 21:48, 26 July 2017 (UTC)

Table in Variants section is wrong

The section headed Variants has a table, in which column 4 (from the left) is headed "Current Value." The first value in that column supposedly shows the Julian Date for the current day and time, but its value is too small by about 12 days. As I look at it now (23 August, 2017, which is JDN 2457989), it shows 2457977.33264. (I said the difference is about 12 days, because it is not yet noon, so that would account for a difference of 1 day, but that still leaves it 11 days short.) I did not check the other values in that column, but they are probably all wrong if they are all derived from the Julian Date, as one could reasonably conclude from the information in the preceding column, headed "Calculation."

If the information shown in that column cannot be relied upon, it is better to delete that column altogether. Meanwhile, I will edit the page to include a warning that the values shown there are unreliable. Mottelg (talk) 04:19, 23 August 2017 (UTC)

The correct figure is shown for me. Perhaps you are viewing a cached value. --Nike (talk) 06:29, 23 August 2017 (UTC)

Method of Peter Baum

This C code implements the method of Peter Baum to convert a Julian day number to a calendar Date including JD < 0:

void JDToDateBaum(double jDNum, int *month, double *day, int *year)
{
int Z, Y, C, A, B;
double R, G;

if(jDNum > 2299160.0){    //Gregorian?
    Z = floor(jDNum - 1721118.5);
    R = jDNum - 1721118.5 - Z;
    G = Z - 0.25;
    A = floor(G / 36524.25);
    B = A - floor(A / 4);
    *year = floor((B+G) / 365.25);
    C = B + Z - floor(365.25 * *year);
    *month = Integer((5 * C + 456) / 153);
    *day = C - Integer((153 * *month - 457) / 5) + R;
if(*month > 12){
    *year += 1;
    *month -= 12;
    }
    }
else{    //julian
    Z = floor(jDNum - 1721116.5);
    R = (jDNum - 1721116.5) - Z;
    Y = floor((Z - 0.25) / 365.25);
    *year = Y;
    C = Z - floor(365.25 * Y);
    *month = Integer((5 * C + 456) / 153);
    *day = C - Integer((153 * *month - 457) / 5) + R;
if(*month > 12){
    *year += 1;
    *month -= 12;
    }
    }
}
Senor Cuete (talk) 19:22, 26 September 2017 (UTC)

References