Talk:Julian day

From Wikipedia, the free encyclopedia

Time Portal

This article is within the scope of WikiProject Time, an attempt to build a comprehensive and detailed guide to Time on Wikipedia. If you would like to participate, please join the project.

???

This article has not yet received a rating on the quality scale.

???

This article has not yet received a rating on the Project's importance scale.

[edit] Solar Cycle

The 28-year solar cycle mentioned in the "history" section is clearly not the 11-year solar cycle linked to in that section. Where should the link be pointing? --Carnildo 23:27, 27 Oct 2004 (UTC)

The appropriate article does not seem to exist yet in Wikipedia. It should describe the 28-year cycle of the days of the week on which any specific date in the Julian calendar recurs—the product of a quadrennium (a four-year period with one leap day) and a week (of seven days) (4 × 7 = 28). Another possibility would be an article on the Julian Period (also not yet in Wikipedia) within which its three cycles would be described. — Joe Kress 06:51, Oct 28, 2004 (UTC)

[edit] any Greenwich time

"any Greenwich time" does not parse. Is there more than one Greenwich time? I think they would be Greenwich Mean Time, Greenwich Apparent Time, Greenwich Sidereal Time, etc. Universal Time and Terrestrial Time are time scales derived from GMT, but I don't think that they are called "Greenwich times".

The IAU states:

it is recommended that JD be specified as SI seconds in Terrestrial Time (TT) where the length of day is 86,400 SI seconds.

In some cases it may be necessary to specify Julian Date using a different time scale...The time scale used should be indicated when required such as JD(UT1).

I also do not see it mentioned, but Herschel's proposal for Julian Days (or "days of the Julian Period") had the day starting at noon in Alexandria, Egypt, since Greenwich was not yet accepted by all countries as the Prime Meridian, although he used GMT elsewhere:

The last year of the current Julian period, or that of which the number in each of the three subordinate cycles is 1, was the year 4713 B.C., and the noon of the 1st of January of that year, for the meridian of Alexandria, is the chronological epoch, to which all historical eras are most readily and intelligibly referred, by computing the number of integer days intervening between that epoch and the noon (for Alexandria) of the day, which is reckoned to he the first of the particular era in question. The meridian of Alexandria is chosen as that to which Ptolemy refers the commencement of the era of Nabonassar, the basis of all his calculations.

I will make the edit when I have time.Nike 07:59, 18 Dec 2004 (UTC)

[edit] Alternative name

I know that this is no place for original research, which is why I'm putting this on the talk page. I think the subject of this article is extremely important, and am a bit distressed at how confusing the current name is. Wouldn't it be a lot clearer for us to call this something like "Scaliger-Herschel Date" or so? Scaliger set the epoch, but Herschel established the pattern of its modern use, in which it serves to record the times at which astronomical events are observed. Arkuat 07:50, 2004 Dec 26 (UTC)

"Scaliger-Herschel Date" is not clearer — if anything, it is decidedly unclear. Article names in Wikipedia should be those by which they are normally known, not names which are esoteric such as your suggestion. Although both Scaliger and Herschel made important contributions to the subject, most who know of Julian days or Julian dates (and want to learn more by consulting an encyclopedia) do not know their names, let alone their contributions. I see no reason for changing the article's name. However, you are correct that the name can be confused with other subjects, such as a date in the Julian calendar, but that is a result of history which cannot be changed at this late date. This is disambiguated by the third paragraph "In other contexts", although this is not normal Wikipedia style. The disambiguation could be improved. — Joe Kress 19:25, Dec 26, 2004 (UTC)

Changing the name of the article before changing the name of the thing referred to would of course be a terrible idea. I was talking about changing the name of the thing referred to. Arkuat 21:27, 2004 Dec 26 (UTC)

Julian days have been in use for more than a century in thousands of publications. Are you going to go back and edit all of those after the fact? I agree that the term Julian date is very ambiguous and it would have been better had something else been initially chosen, although maybe not what you suggest. (Maybe Julian day&time.) Herschel referred only to the "day of the Julian period". But Julian day is not a problem, since that term is not used with the Julian calendar, and using it for day-of-year (ordinal date) is considered incorrect, so only that useage needs to be changed. In any event, this is hardly the place to do anything about it. Try the IAU, instead. -- Nike 04:12, 27 Dec 2004 (UTC)

I edited the section on Julian Dates, adding a header and clarifying the language. I simplified the disambiguation part, adding an internal link for ordinal dates instead of defining them in situ. I also put a comment that this usage (often called day-of-year) is considered incorrect. -- Nike 05:04, 27 Dec 2004 (UTC)

[edit] Other epochs, etc.

I'm unclear as to the purpose of this section, and exactly how the facts within it are significant to the article. It starts with some dates listed with no reason given and talks about Microsoft Excel without explaining why. Perhaps there could be a section like, Similar Systems with the contents explained, and the day-of-week stuff put somewhere else. -- Nike 05:11, 27 Dec 2004 (UTC)

OK, I listed the alternatives in this section under Alternatives and moved the day-of-week calculations under Calculations. -- Nike 08:03, 29 Dec 2004 (UTC)

[edit] History

I find the final sentence of the history section to be strangely out of context given the paragraph that it is used in.

Looking over the history of this article, it appears that a previous claim had been made, which stated that one benefit of defining the beginning of the Astronomical day as Noon, was that it allowed all observations in a single night to be recorded as happening on the same date.

It seems reasonable to conclude that this claim probably has nothing to do with the "history" of the definition of a Julian day; therefore, it had no place in the "history" section of the article.

At the same time as that faulty claim was edited out, the following sentence also made it into the article:

"Thus the astronomical day did not begin at noon to allow all observations of a single night to be in a single day."

Standing by itself, without any claim to refute, this sentence makes little sense. Perhaps it should be reworded or omitted?--24.222.2.222 16:32, 15 August 2005 (UTC)

I wrote that paragraph. If I understand you correctly, you would prefer to see the statement that "many believe the Julian day began at noon in order to allow all observations of a single night to be in a single day" first before refuting it. That seems strangely redundant to me. However, the confusion maybe with the final word "day", which is easily misconstrued as 'daylight' rather than what I intended: a 24-hour 'day', also called a nychthemeron (night-day), a direct transliteration from Greek. You may prefer "date" instead, that is, the name assigned to a 24-hour period, which is also correct here. — Joe Kress 19:38, August 15, 2005 (UTC)

[edit] Start of year

"Monday, 1 January, 4713 BC" which year is that in Gregorian calander? Is it assumened that the year 4713 started on 1st of January or some other date? See Old Style and New Style dates and the changes in the day which starts the year. Philip Baird Shearer 17:19, 1 October 2005 (UTC)

You bring up a valid point. 1 January 4713 BC in the proleptic Julian calendar is 24 November 4714 BC in the proleptic Gregorian calendar. Both use historical years beginning on 1 January. The article on Old Style and New Style dates confuses the change in a date from Julian to Gregorian with a change in the beginning of the year because English law changed both at about same time. The Gregorian calendar did not change the beginning of the year. Most Western European countries had already changed it during the sixteenth century to 1 January before the Gregorian calendar was promulgated in 1582 (see Gregorian calendar#beginning of the year). To this day papal bulls are dated using a year beginning 25 March. — Joe Kress 18:16, 1 October 2005 (UTC)

The Gregorian calendar may not have changed the start of the year, but the reason why the terms Old Style and New Style are used in English instead of simply Julian and Gregorian for the transition period is because the two are mixed up in the same British legislation. Samual Pepys for example happily state that January 1st is the New Year [1] (more than 150 years before the legal change) while at the same year (NS) the House of Commons can be styling the month of execution of the King as January 1648[2] which is 1649 NS! Philip Baird Shearer

I've already mentioned your last point in Gregorian calendar#beginning of the year. January 1 was called "New Year's Day" during the same years that the number of the year changed on March 25. Henry VIII and his court exchanged presents on January 1 to celebrate New Year's Day. A good reference is Reginald Lane Poole, "The beginning of the year in the Middle Ages" (1921). — Joe Kress 06:42, 2 October 2005 (UTC)

The UK tax year still starts on 6th April for the same reason as papal bulls. (which is 25th of March plus the number of days differnce between the two calanders at the time the UK converted) :-) --Philip Baird Shearer 19:16, 1 October 2005 (UTC)

Actually, the UK tax year should start on 7 April to account for the now 13 days between the calendars. But it still begins on 6 April because the skipped leap day of 1900 was ignored, even though that of 1800 did shift the tax year from 5 April in the last half of the eighteenth century to 6 April in the nineteenth century. See the discussion at Talk:Fiscal year. — Joe Kress 06:42, 2 October 2005 (UTC)

True, but the day chosen is primarily to do with the conservatism of the financial industry in the UK rather than any truly rational reason. In 1800 the Gregorian calendar, was still a new fangled thing, by 1900 it was not. And not just in the UK It was only with the introduction of the Euro that most calculation of bond coupons in the Euro region moved to actual/actual. Philip Baird Shearer

It is clear from the Julian year discussion page that Philip is confused about the differences between Julian calendar, Julian year and Julian date. The reason that the Julian Period begins on the day it does is because it is based upon the proleptic Julian calendar, specifically being defined as beginning on January 1. The Julian Period was named in the 16th century, before England ever changed its dating system, and its use was extended in the 19th century to include the Julian day count. The proleptic Julian calendar does not depend upon actual historical use, which varied from place to place and time to time, but is a continuous method of dating retroactively that is immune to the vagaries of dating styles. --Nike 05:52, 2 October 2005 (UTC)

"It is clear from ... that Philip is confused". Perhapse you would like to rephrase that? (Wikipedia etiquette and all that). Until you explicitly say so I will take it that you meant "I think Philip is confused...".

The introduction of the "Julain Period" which links to "Julian Day" includes the following: "The Julian day system was intended to provide astronomers with a single system of dates that could be used when working with different calendars and to unify different historical chronologies." So it does have to do with "actual historical use" and the start of the year has to be taken into account. If not then that sentence needs to be removed from the article. One has to be aware that when calculating the day that an event took place it can be done precisely, but as soon as one starts to overlay months and years onto that day so that it can be matched to an historical event, then arbitrary start of the year (and the calculation of how long that year is) must be taken into account when matching a celestial event to an historic event. Philip Baird Shearer 11:03, 2 October 2005 (UTC)

You keep repeating your confusion between several different things, which happen to share the term "Julian". The Julian Period was named by a chronologist in the 16th century. Julian days were introduced by astronomers in the 19th century. Julian years I believe were first used in the 20th century. Nobody is using Julian years to date historical documents. Julian days are sometimes used to date historical documents, but "New Style" and "Old Style" dates are only two of many different dating styles that are converted to and from Julian days, so it makes little sense to single just them out, and no sense at all to talk about them in the Julian year article.

Not only are you confusing Julian years with Julian calendar years (and I do recognize that the term is misleading and ambiguous) but you are also confusing Julian years with the Julian day system. Julian days and Julian years can be easily converted, because every four Julian years contain an integer number of days, which is not true of other types of years, but Julian years are not dependent upon Julian days, nor are Julian years the same as years of the Julian calendar. In fact, Julian years were designed to correspond more closely with the Gregorian calendar.

Let me put it this way: Charles I was executed on January 30, 1649 NS, which was January 20, 1649 in the Gregorian calendar. Assuming that was exactly at noon in London, that's Julian Day 2323364.5. Since J2000.0 = JD 2451545.5, then 2451545.5 - 2323364.5 = 128181 days elapsed between these two dates. That equals 128181/365.25 = 350.940... Julian years, so that event happened at Julian year J1649.060... Note that J1649.0 = JD 2323342.75 = December 28, 1648, (Gregorian) at 6 am GMT, which was January 7, 1648 OS, or January 7, 1649 NS.

Regicide is not an astronomical event! --Nike 05:39, 3 October 2005 (UTC)

Well not unless you are a 5th monarchy man ;-) BTW I do not think I am confused, I am only sorry that I am unable to write precisely enough so that you can read the idea I am tying to convey. If you were to look for the execution in the English historical record you would find that it happened on the 30th Jan 1648. Philip Baird Shearer 06:57, 3 October 2005 (UTC)

I have no problem understanding you. I get the difference between OS and NS. January 30, 1649 NS is the same as January 30, 1648 OS. What you are not getting is that it has nothing to do with the astronomical article on Julian years. --Nike 21:55, 3 October 2005 (UTC)

and to unify different historical chronologies. --Philip Baird Shearer 08:54, 4 October 2005 (UTC)

Which has nothing to do with a Julian year, which is the article you keep changing. --Nike 18:46, 4 October 2005 (UTC)

[edit] Leap seconds

83.250.196.61 changed:

For the full Julian Date

to:

For the full Julian Date, not counting leap seconds

With the comment:

It seems that the formula does not account for leap seconds.

However, the article says:

the International Astronomical Union now recommends that Julian Dates be specified in Terrestrial Time

Terrestrial Time (TT) does not have leap seconds, which is why it's preferred. But even if we were to use UTC, the difference would be pretty small. The difference between 1/86400 and 1/86401 is about 0.0000000001 day. If we are using a precision to the nearest second, that is not significant, since a second is about 0.00001 day. It would be significant if we were stating the time to the nearest microsecond, but this is unlikely. --Nike 06:16, 7 October 2005 (UTC)

Do not edit other people's comments in talk. My original statement is correct, anyway. The difference between 1/86400 and 1/86401 is about 0.0000000001. To be more precise, 0.000011574074074074074074074074 day - 0.000011573940116433837571324406 day = 0.000000000133957640236502749668 day. --Nike 09:38, 18 May 2006 (UTC)

That's correct: in Terrestrial Time, every day has 24 hours of 60 minutes of 60 terrestrial seconds exactly (but the effective length of the observed TT day is variable).

The difference is that the TT second is not the SI second and varies over time according to irregularity of the dayly earth rotation according to the observed Sun longitude from the same reference location on Earth (note that this observed TT second depends on the location on earth! So TT time is defined at the longitude/latitude location of the observatory of Greenwhich).

That is not correct. You are confusing TT with UT. TT is a uniform timescale, which, by definition, means that it does not vary. The TT second is the SI or atomic second, and differs from International Atomic Time (TAI) by a constant number, 32.184 s. It is UT which varies. UTC follows UT1, not TT. TT and UTC currently differ by over a minute (65.184 s, I think) a difference which increases every time a leap second is added. --Nike 09:49, 18 May 2006 (UTC)

UTC time tries to follow TT time with an error of at most 1 second, but UTC time does this using fixed-length SI seconds, that's why it inserts or removes leap seconds (SI seconds) occasionally on specific dates announced afew months before (leap seconds occur every 6 or 12 or 18 months), to maintain UTC time within 1 second of the observed TT time.

What the IAU does not indicate in this recommendation is how we can compute TT time from UTC time. This is a very complex formula, and so, systems are built with clocks that measure SI seconds, and these system clocks are resynchronized only occasionally with UTC.

Those systems just use SI seconds as if they were TT seconds, and when resynchronization occurs, the adjustment is made either abruptly or by instructing the clock to slow down slightly (when adding a leap second) or speed up (if a anti-leap second is subtracted) for some long enough time until the estimated correction is achieved (as long as the clock drifts, the system clock will no longer count SI seconds, but will count seconds slightly altered depending on the desired time adjustment and total duration of the correction).

This drifting clock requires specific hardware for the RTC clock, but it is inconvenient for the rest of the system which requires a constant second (notably when producing sound/music, or synchronizing with buses, or to synchronize an output video signal). For this reason, the system maintains a separate clock (with an artitrary epoch, generally the system start time) which is not sensitive to the RTC clock drift during corrections.

Most PC hardware do not have the necessary hardware in their RTC clock, and this RTC clock is too slow for accessing it and not enough preciseto support slow drifts. So instead, the RTC clock is emulated (the system just records the difference between the emulated RTC clock time andthe system time (which is not sensitive to time adjustments),and the physical RTC clock is adjusted immediately but not read after system boot time.

05:18, 15 May 2006 (UTC)

[edit] Inverse Calculation

The calculation section ought to include the inverse functions, that is, the formula for year, month, and day given Julian day number. Here is one way to perform these calculations:

To get the Gregorian date from JDN, begin by computing n as follows:

n = JDN + 32044
c = (4*n + 3)/146097
n = n + (3*c + 3)/4

To get the Julian date from JDN, begin by computing n as follows:

n = JDN + 32082

In either case, complete the calculation as follows:

y = (4*n + 3)/1461
n = n - 1461*y/4
m = (5*n + 2)/153
a = (m + 2)/12
day = n - (153*m + 2)/5 + 1
month = m + 3 - 12*a
year = y + a - 4800

(DHM 20:40, 26 December 2005 (UTC))

[edit] Wrong calculation formula?

I have done the calculation as given (with the note on integer division) and found that it gives wrong results!

For example, jdn for 2nd January 1006, 00h:00, you will find 2088495, which is about 5.5 days different from the accurate value of 2088500.5.

Can someone verify this?134.157.170.125 15:54, 2 January 2006 (UTC)

As for the 5.5 days, that is the difference between the Julian calendar and the Gregorian proleptic calendar, plus an error caused by counting from midnight instead of noon. The difference between the two formulas in the 11th century is actually 6 days. It should be remembered that the Julian and Gregorian calendars diverge by 3 days every 400 years. That is why there is a different formula for each one in the article. January 2, 1006, in the Julian calendar is actually January 8, 1006, in the Gregorian proleptic calendar. The Julian Day starting at noon GMT on January 2, 1006, on the Gregorian proleptic calendar is JDN 2088495, and tbe Julian Day starting at noon GMT on January 2, 1006, on the Julian calendar is JDN 2088501. You have to use the corresponding formula in the article depending upon which calendar you are using. The point of time given above, "2nd January 1006, 00h:00", is actually the middle of JDN 2088494, or JD 2088494.5, for the Gregorian proleptic calendar. 2088500.5 is actually a Julian Date, rather than a Julian Day Number, referring specifically to midnight GMT on January 2, 1006, of the Julian calendar, which is the middle of Julian Day Number 2088500. --Nike 01:50, 3 January 2006 (UTC)

So there's nothing wrong in the implemented formulas. Note:

Date 1006-01-02 in the proleptic Gregorian calendar at 12:00:00 UTC is JDN 2088495 exactly.
Date 1006-01-02 in the Julian calendar at 12:00:00 UTC is JDN 2088501 exactly.

Both calendars treat the time of the day equally when computing the JDN, because the JDN is integer only at noon (the default when computing JDN is to consider time is noon).

Date 1006-01-02 in the proleptic Gregorian calendar at 00:00:00 UTC is JDN 2088494.5 exactly.
Date 1006-01-02 in the Julian calendar at 00:00:00 UTC is JDN 2088500.5 exactly.

There's effectively a difference of 5 days in the two calendars in year 1006. Now the difference is 12 days in 2006:

Date 2006-01-02 in the proleptic Gregorian calendar at 12:00:00 UTC is JDN 2453738 exactly.
Date 2006-01-02 in the Julian calendar at 12:00:00 UTC is JDN 2453751 exactly.

Both calendars are synchronous on March 21, 325 AD at noon:

Date 0325-03-21 in the proleptic Gregorian calendar at 12:00:00 UTC is JDN 1839843 exactly.
Date 0325-03-21 in the Julian calendar at 12:00:00 UTC is also JDN 1839844 exactly.

verdy_p 04:32, 15 May 2006 (UTC)

JDN is always an integer. JD is a real number. The Julian Day number remains the same from one noon GMT to the following. For instance, 2453737.0, 2453737.5 and 2453737.99999 are all Julian Dates which occur during Julian Day 2453737. A Julian Day is a 24-hour day, and the Julian Day number is the integer which corresponds to that 24-hour period. A Julian Date is the Julian Day number plus the fractional day representing the time from the beginning of that Julian Day. I explained this in detail here, but that exlanation was deleted.

Thus, there is no "JDN 2088494.5", but JD 2088494.5. Instead of "JDN 2453738 exactly", say JD 2453738.0. --Nike 23:08, 19 May 2006 (UTC)

I think there's a problem with the formula given for Gregorian-to-JDN. I plugged in today's Gregorian date (20 Nov 2006)and got approximately 2,454,061.14 -- the result should have been exactly 2,454,060.

[edit] Calculate Julian Day for first day of a year

Algorithms used frequently in computer programming include:

Julian Calendar: will yield the Julian Day for 1st January of that year $((y e a r + 9998) * 365) + ((y e a r + 9999) / 4) - 1930711$

Gregorian Calendar: will yield the Julian Day for 1st January of that year $((y e a r + 9998) * 365) + ((y e a r + 9999) / 4) - ((y e a r + 9999) / 100) + ((y e a r + 9999) / 400) - 1930634$

HoCkster 18:09, 4 January 2006 (UTC)

Completely wrong formulas: it gives leap years in year 1, 101, 2005, 2009, 2013... and 1600, 1601, 2000, 2001 would be normal years, but 1801 and 2201 would be leap! In addition your formula uses a different epoch, meaning that it returns a JDN offseted by an arbitrary additive contant. (Most probably, your program uses offseted years counted since January 1, 1801 AD). Use instead the formulas in the article. If you want just the JDN for January 1, apply the formula and precompute the constants.

verdy_p 04:42, 15 May 2006 (UTC)

These algorithms are fine, so long as the divisions are truncated (int or floor) and we're talking about the day beginning at noon GMT. 1801 and 2201 are not calculated as leap years. I don't know where you got that from. 1801 is 2378862 and 1802 is 2379227, a difference of 365 days. Likewise, 1800 is 2378497, which is 365 days less than 1801. I created a program using the Gregorian formula and it correctly printed Julian Day numbers for years 1600-2020.

HoCkster states that these are "used frequently in computer programming". As such, they would be notable. What does it matter that they have an arbitrary constant? (It's actually subtractive.) The formulas in the article also have constants. Programmers probably like them because they are simple and they work. There are many other algorithms which have been used which also work. See the U.S. Naval Observatory for more formulas. --Nike 23:45, 19 May 2006 (UTC)

[edit] Gregorian date elements

The correction of the Julian calendar was completed in 4 AD, not 32 AD. Furthermore, the dates for the year before Julius Caesar's death, 45 BC, do not match the proleptic Julian calendar. For a good discussion of the early Julian calendar and its correction by Augustus, including citations to Roman literature, see Roman dates. I assume that 'euclidian division' means integer division. Self reference to Wikipedia is not allowed in a Wikipedia article, so I commented out the ParserFunctions discussion—it can still be consulted in edit mode. This section is much too large (90 KB) and should be drastically reduced by only including the algorithm itself—all internal calculations should be removed. Wikipedia articles should not exceed 32 kilobytes. This section is essentially useless before 1582 because the proleptic Gregorian calendar is almost never used—the Julian calendar and proleptic Julian calendar are almost always used before 1582. There is no such thing as a UTC calendar. — Joe Kress 11:29, 14 May 2006 (UTC)

The UTC/astronomical calendar exists: it is the extension of the Gregorian calendar that covers the period before its adoption, and it is different from the proleptic Gregorian calandar in the way it handles historical dates before the Christian era, and in the way it computes leap years in that period (because in the UTC/astronomical calendar there's a Year Zero).

I did not use the term "astronomical" because astronomy uses now a much more precise timescale where seconds, minutes, hours, days, weeks and years have constant duration according to the SI definition of the second. By "UTC" calendar I mean here that it matches the length of the observed days and years on Earth, even if those terrestrial units are varying over time, most notably across seasons, and with the influence of the moon and its complex movement, or with the variations of the Earth rotation speed depending in its relative position to the Sun and other astral objects, or with major earthquakes).

As the UTC clock tries to match the most exactly as possible the observed day and year on Earth, it's the best term I can use to designate this terrestrial/Platonic calendar, and also because it fixes a single point of observation on Earth on the meridian of Greenwhich (so it does not depend of local timezones).

Now with those definitions, the formulas are exact. Other interpretations and adjustments must be made to match other calendars used before 1582 (and don't think it's simple: even "the" Julian calendar is not unique through the history and regions, so NEARLY ALL dates found in historical documents MUST be corrected according to the country or culture, notably because the definition of the day greatly depends on the location and culture, long before timezones where created.)

However, having an exact reference calendar will really help making the adjustments, because most variations found in many locations and cultures differ only by one or two days from this common reference. To get the exact offset is impossible to do in most cases, because historical documents often don't contain enough details (so a location and culture must be infered from the author, or the language and notation used. In the history, the most stable reference frame was the week and often this allows to get the offset information with a precision of one day (less if there are indications like "morning", "afternoon", "night". But interpreting time is often not easy because time of day was standardized very lately in the History. There are enough imprecisions thatwe need a reference calendar to order things in the History.

verdy_p 04:07, 15 May 2006 (UTC)

Your concern about the astronomically numbered proleptic Gregorian calendar is misplaced. There is no such thing as a calendar composed of constant SI days, certainly not in astronomy. Although an astronomical SI day is exactly 86,400 SI seconds, these days are never collected into Gregorian months, years, or centuries. Rather, they are collected into Julian years and centuries (never months), where each Julian year contains exactly 365.25 days (not 365 or 366 days). An astronomical century always contains 36525 days, never 36524. A single meridian on Earth is unnecessary in calendar calculations—regardless of the time zone, UTC or otherwise, the calendar calculation will be the same. The difference between the proleptic Gregorian calendar and the Julian calendar is not "one or two days"—it reached ten days in 1582. No one ever tries to calculate any of the many historical variations in the calendar—the dominant standard is to assume that the Gregorian calendar existed since October 15, 1582, and that the Julian calendar existed prior to that date, even before AD 4, when it is called the proleptic Julian calendar.

I greatly reduced your notes because they were wrong. According to Macrobius in "Saturnalia" (~AD 430), the Julian calendar for 36 years between 45 BC and 8 BC had a leap year every three years instead of every four years. The extra three days were removed by Augustus by declaring that the next twelve years would all be common years. However, which year was a leap year within this overall period is debatable because neither Macrobius nor any other Roman writer gave those details. Also, your explantion implied that the month of August got that name either in AD 32 or shortly thereafter, whereas Macrobius specifically states that the name was changed in 8 BC.

My problem with your 153-day explanation is that there are also 153 days in the months March to July and in August to December, just as there are from May to September and in October to February (terminated at February 28/29). But the sequence is different, March to July and August to December are both 31 30 31 30 31. January to February can also be regarded as the first two months of that sequence, terminated at February 28/29. Your sequence is 31 30 31 31 30, which is irregular, and you must handle March and April separately because of the irregularity at the end of February.

Euclidian division of a/b means a = qb + r (all integers), but no programing language provides both the quotient q and the remainder r. Instead, div (integer division) yields q, and mod (modulo) yields r. — Joe Kress 09:19, 17 May 2006 (UTC)

I cannot find the term "UTC calendar" in general use online, and from the comment above is obviously original research, and therefore should not be used in this encyclopedia. Likewise, there is no "astronomical calendar". There is astronomical year-numbering, but that does not equal a calendar, and has nothing to do with the UTC standard.

I also question whether all the new information about conversion is notable enough to include. It makes the article rather tedious and long, and probably not very useful for most readers. If the information is available elsewhere, a simple offsite link would suffice. --Nike 10:10, 18 May 2006 (UTC)

I agree that all of the hidden calculations in the table must be removed. They never change and will never be seen by readers of the article, especially when copied onto other sites or in future print. I am not so sure about the visible explanation and algorithm, giving the benefit of the doubt to verdy_p for the moment. However, the table is mostly test numbers, which are essential for its development but useless to the reader (except in understanding it). Of course, it is just another algorithm for obtaining the date from the JDN. That given above in #Inverse Calculation is quite similar to verdy_p's and which he agreed was correct. Yet another is given by Jean Meeus in "Astronomical Formulae for Calculators", but it uses real number division to which verdy_p objects (even though no error results). — Joe Kress 06:29, 19 May 2006 (UTC)

[edit] Article length

When editing this article, a warning appears:

This page is 103 kilobytes long. This may be longer than is preferable; see article size.

According to the linked style guide, the recommended maximum is 32 KB, or 50 KB at most. This article is now several times the recommended size.

I think that it would be a good idea to split off the whole calculation section. This section is very technical and probably not of much interest to many readers. The alternatives section might also be expanded into a separate article. --Nike 06:33, 1 June 2006 (UTC)

The reason for the length has nothing to do with what is visible — the vast majority of the length is due to the invisible calculations imbedded in the table for calculating the date from the Julian day added by Verdy_P. All of those calculations must be removed — they don't belong in any article on Wikipedia. Only the results should remain, and even they are problematic. — Joe Kress 19:50, 2 June 2006 (UTC)

You're right, most of the bytes are not visisble. However, the style guide says:

Readers may tire of reading a page much longer than about 6,000 to 10,000 words, which roughly corresponds to 30 to 50 KB of readable prose.

I counted about 18,000 readable words, which is still excessive. There's a huge table, which I don't see as all that useful.

Also, Tim Starling deleted the JD template from the article a couple of months ago because he said it uses up too much CPU time. Now I see that a similar template is being used, where it says:

Currently the value is 2454626.9664699 - 2400000.5 = 54626.4664699.

Is the CURRENTJULIANDAY template somehow different from the JD template in CPU usage? I seem to recall that templates which gave the current time were generally discouraged. --Nike 22:05, 2 June 2006 (UTC)

I have removed all of the 'hidden' calculations and the table, reducing the size of the article to 29.5 KB. The intermediate calculations and the test dates were no longer useful after the algorithm was developed. I also removed the 'Roman' dates because they had no relation whatsoever to the Roman calendar after its stabilization by Augustus, meaning the Julian calendar. I also corrected the explanation in the JDN calculation—the JDNs are not the same on March 21, 325. I do not know anything about the CURRENTJULIANDAY template. — Joe Kress 05:37, 3 June 2006 (UTC)

[edit] A pair of floating-point algorithms for Gregorian Date / Julian Day Number conversion

These floating-point algorithms convert between Gregorian Date (day,month,year) and Julian Day Number (jdn). They are valid for Gregorian or Proleptic Gregorian calendar dates on or after 1 March of the year zero. Brackets [] denote integer part.

Gregorian Date to Julian Day Number

a=[(14-month)/12]
y=year-a
c=[y/100]
jdn=1721089+day+[30.59*(month+12*a-2)]+[365.25*y]-c+[c/4]

Julian Day Number to Gregorian Date

n=jdn-1721089
c=[(n-30.1)/36524.25]
n=n+c-[c/4]
y=[(n-30.1)/365.25]
n=n-[365.25*y]
m=[n/30.59]
a=[m/11]
day=n-[30.59*m]
month=m-12*a+2
year=y+a

--192.102.214.6 08:12, 7 September 2006 (UTC)

[edit] Fliegel & Van Flandern's algorithms

Fliegel & Van Flandern's algorithms provide an efficient and reliable way to convert between Julian Day Number and Gregorian Date, and are valid for all JD>=0. The algorithms are shown here with optimised constants. \ represents integer division, ie discarding the fractional part.

Gregorian Date (Y,M,D) to Julian Day Number (J)

A= (14-M)\12
M= M+12*A+1
Y= Y-A+4800
J= D+(153*M)\5+365*Y+Y\4-Y\100+Y\400-32167

Julian Day Number (J) to Gregorian Date (Y,M,D)

D= J+68569
Y= (4*D\146097
D= D-(146097*Y+3)\4
C= (99*(D+1))\36160
D= D-(1461*C)\4+31
M= (5*D)\153
A= M\11
D= D-(367*M)\12
M= M-12*A+2
Y= 100*(Y-49)+C+A

--192.102.214.6 08:17, 7 September 2006 (UTC)

[edit] Date/JDN Conversion Algorithms for a Herschel-Compliant G'n Calendar - anyone?

Can any of the mathematicians amongst us suggest how the two formulae given in the main article can be adapted to work for a Gregorian calendar that is (what I call) "Herschel Compliant" (i.e. one in which years divisible by 4000 are common years)?

The 19th Century astronomer, John Herschel, and others suggested amending the leap-year rules of the Gregorian calendar to include this rule, which would have the effect of reducing the mean length of a Gregorian calendar year from 365.2425 days to 365.24225 days, making it a better approximation of the mean length of a tropical year (a full cycle of seasons), which is ~365.24219... days. Herschel's suggestion has not been officially adopted; the leap-year rules presently provide that ALL years divisible by 400 are leap years.

I have tried adapting at least the first formula (Date to JDN), but my maths skills are not up to the task. Clearly, I haven't understood how it works as well as I thought I did.

Using a simple counting program, I have discovered that for such a calendar, the correct value for the constant used at the end of the formula should be -32403. This is the JDN of Feb 29, -4800 in a Herschel-compliant Gregorian proleptic calendar. I have tried using this value and, at the same time, subtracting Y\4000 from the terms that account for the Gregorian leap years, but it still doesn't work correctly. Can anyone help?

Note that in a Herschel-compliant Gregorian calendar, the YEAR ZERO (1 BCE) IS A COMMON YEAR. Mottelg 03:21, 14 April 2007 (UTC)

This is not appropriate here. The talk page is for discussing the article only. This article is not about changing the Gregorian calendar. There are other places online where this idea has been discussed, and Herschel and the others who suggested it before and after him were mistaken, anyway. Contact me privately if you want to know more. --Nike 08:34, 14 April 2007 (UTC)

I have tried to contact you personally through your user-page (the discussion tab). Sorry, but I can't see any other obvious way of doing so. As for my above post being out of place because this page is not about changing the Gregorian calendar, please note: This page is about the JDN, not about a specific calendar, Gregorian or otherwise. The major function of the JDN is that it can be used to unify DIFFERENT calendars and chronologies. Therefore, in a discussion on the JDN and its use, it is entirely appropriate to inquire about how it can be correlated to other calendars. Much of the discussion on this Talk page centres around the conversion algorithms given in the main article and similar ones offered on this Talk page. This is about finding out more about how they work and how they can be adapted to another calendar. As such, it is entirely "on topic".

Mottelg 09:19, 14 April 2007 (UTC)

It is entirely not on topic. As I said, the sole purpose of this talk page is to discuss the article, period. It is not for discussing the subject of the article, but the content, what should be added, removed or modified in the article. It is not for talking about related subjects. What you are proposing is called original research, which is a major no-no on Wikipedia. See Wikipedia:No original research. Algorithms for calendars which currently do not exist are not appropriate for this article, which means that it is also not appropriate to discuss them here. Really, just ask anyone who has been here a while. It is not that I am against talking about it, since I have done so elsewhere. It simply should not be done here. This is not a free-form bulletin board. There are already a number of other places on the Web to discuss calendar reform. You should take it there. The article does not need algorithms for every calendar that has ever existed, let alone those which have never existed, and in fact, I think that there is already too much of this stuff for an encyclopedia article.

You already contacted me through my talk page, which is the correct way to do it. You need to be patient, since people are not awake and online 24 hours a day. I have already responded to you there, and by email, which is another way to contact people here. --Nike 22:05, 14 April 2007 (UTC)

OK, I can see your point now, it's not that I was discussing the "wrong" calendar, but because the discussion was not about how the main atricle should/can be improved. Fair enough. If anyone can help with my request, please contact me privately (see my user-page, just newly created). What follows below, however is quite on topic by the criteria mentioned above by Nike.

The needs of users in consulting a reference work like Wikipedia are as diverse as the users themselves. In my case, I consulted this article on the JDN precisely to obtain information on how to calculate it and convert to/from JDN and date. What I found most invaluable was not just the algorithms presented, but also the explanations that went with them and I, for one, would be very pleased to see that material not only retained but expanded upon. E.g. the Date to JDN algorithm could do with some detailed explanation of the type that appears below it with the JDN to date algorithm, and the latter could also do with some improvements in a few places where it is still a little obscure. I can't see why people would want to excise or limit good information like this. Personally, I find it of much more practical use than, say, info about the history of the JDN, though I am not suggesting you remove any of that either. My two-cents worth: the more inclusive the better; people don't HAVE to read what doesn't interest them, but being able to readily find information that you DO want is what makes Wikipedia such a useful resource. Mottelg 13:30, 15 April 2007 (UTC)

You're missing my point. I'm not saying that information be limited. What I am saying is that the presentation may make it more difficult for someone to find the information they are looking for. When articles get too much information, they should be broken down into separate articles. Someone who is merely looking for general information could get lost in all the math. Also, the purpose of an encyclopedia is not to contain all possible information on a subject, but to summarize it and give references where one may find more information. There are many places to find such algorithms, and it would be appropriate to list these references. If there is a lot of information, then breaking it out into separate pages makes it easier for people seeking different information to find just what they are looking for, without having to wade through the irrelevant stuff, which in your case is the history. But since people have already done the calculations, it may be better to simply link to offsite resources, rather than trying to move everything in the world into the article. --Nike 22:11, 15 April 2007 (UTC)

[edit] Chronological Julian Day (CJD)

The formula given to calculate CJD from JD is:

CJD = JD + 0.5

This means that CJD starts at 4713-01-01 24:00 BC, i.e. 4713-01-02 0:00 BC.

But from http://www.hermetic.ch/cal_stud/jdn.htm, chapter 5, 3rd paragraph:

chronological Julian date 0.5 is noon GMT on -4712-01-01 JC

So the correct formula is:

CJD = JD - 0.5

Leendert Meyer --82.73.198.206 11:25, 14 October 2006 (UTC)

No, your operator is wrong. Look: CJD 0.5 = "noon GMT on -4712-01-01 JC", but this is JD 0.0. Therefore, CJD = JD + 0.5, because 0.0 + 0.5 = 0.5. By your formula, noon GMT on 4713-01-01 would be 0.0 - 0.5 = -0.5. What you seem to be thinking is JD = CJD - 0.5.

This formula only works for local time GMT. It needs to be adjusted for other time zones. For instance, Jerusalem mean time is about 2h20m ahead of GMT, and civil time is GMT+2h. 2h20m is just under 0.1 day, so the correct adjustment for JMT is CJD = JD + 0.5 + 0.1 for Gregorian calendar dates, while civil time is slightly less. However, when using Jewish and Muslim calendars, the calendar day starts at sunset the previous evening, so to this you have to add about 0.25, plus or minus. (Today it was 15:08 GMT, or about 0.37 day before midnight GMT, so at 2006-10-14T23:17Z = JD 2454023.47, CJD = JD + 0.5 - 0.37, or CJD 2454023.6 for Tishri 23.) CJD is always relative to the local time and calendar, unlike JD, which is relative to GMT or its relatives. (UTC, ET, TDT, TT) Currently, CJD in Greenwich, England, is JD + 0.5 + 0.0416667, because civil time is currently British Summer Time, which is one hour ahead of GMT. --Nike 23:38, 14 October 2006 (UTC)

Sometimes the simplest things can be the most deceptive. With the two time scales drawn on paper one below the other:

 JD --> -0.5  0    0.5
CJD -->  0    0.5  1

I saw clearly that my reasoning was wrong. I remember now that one of my former teachers once told us to "Draw it on paper or you will make a mistake!". He was right. --82.73.198.206 13:56, 15 October 2006 (UTC)

 CJD = MJD + 2400001  and
 CJD = TJD + 2440001

Is this right?

And if it is, Why does the CJD round that extra half-day backwards in time (+.5) (midnight 31st Dec, or 00 1st Jan), while the MDJ and TJD round it forwards in time (-.5) (midnight 1st Jan, or 00 2nd Jan)?

I wish they all used +.5, to keep the split at the new-year moment (at least in the proleptic Julian calendar). --rocky

Because different people made them up without consulting each other.

BTW, midnight (12:00 am or 00:00) is considered part of the following day, not the previous, so midnight 1st Jan would be the beginning of January 1, i.e. 00:00. You could say 24:00 on the previous day, but it's best to simply say 00:00 on the following day, so that it's clear which midnight you are referring to. --Nike 20:10, 10 January 2007 (UTC)

JD MJD CJD CMJD

Rather than concentrating on the numeric differences, I think it that would be better to describe those initially by tabulating their starting dates in ISO 8601 form - from memory :

  JD    Julian    BC 4713-01-01 12:00:00 UT
  CJD   Julian    BC 4713-01-01 00:00:00 LCT
  MJD   Gregorian AD 1858-11-17 00:00:00 UT
  CMJD  Gregorian AD 1858-11-17 00:00:00 LCT

where LCT is Local Civil Time, used when the offset from GMT is not germane. And noting that

Julian BC 4713-01-01 = Gregorian BC 4714-11-24 = 
Julian   -4712-01-01 = Gregorian   -4713-11-24

Check for typos there.

82.163.24.100 22:22, 9 February 2007 (UTC)

These terms are not even used in the article. --Nike 07:45, 10 February 2007 (UTC)

Semi-correct, of course; JD and MJD are already in the article. That is exactly why I pointed out the existence of CJD and CMJD; they should be in the article. Sometimes, the term used elsewhere is JD when the date is local and CJD would be appropriate. CJD is in the Talk above.

Such a table of origins would facilitate intercomparison, and help to ensure that information was complete and unambiguous. For each entry in such a table, one could add on the right its JD or CJD, whichever is appropriate.

The article does not say whether ANSI date uses local or "Greenwich" time. A section in Hynes's site has that omission, but the point is covered in his table above.

Google finds claims that "ANSI date" is YYYY-MM-DD hh:mm:ss am/pm (12-h!!). But I've not found "ANSI date" defined on the ANSI site, and they use instead FFF date form, mm/dd/yyyy.

82.163.24.100 11:53, 13 February 2007 (UTC)

By these terms, I refer to CJD and CMJD, neither of which are currently in the article. CJD was removed for not being notable. I never even heard of CMJD, and it seems to be even less notable. You seem to be confusing the ANSI COBOL standard integer date with the ANSI/ISO format for representing Gregorian calendar dates. There are many different ANSI standards. The article refers specifically to COBOL integer dates, which have an epoch of midnight GMT.[3][4] --Nike 15:31, 14 February 2007 (UTC)

[edit] Start dates

Would someone who knows please say WHY the various start dates were chosen? Some [end of 1800s, the year before the end of the 19th century] may be convincingly guessed. But WHY?:

Monday, January 1, 4713 BC?

Wednesday November 17, 1858/Tuesday November 16, 1858?

May 24, 1968?

December 31, 1899?

October 15, 1582 [which was the first day of the Gregorian Calendar, OK]

January 1, 1601?

any others?

Thanks! ... OK, I did notice Herschel's comment, but I either don't remember or never knew why he considered that the epoch. —Preceding unsigned comment added by 63.40.196.166 (talk • contribs)

As far as I can see, all start dates are adequately explained in the article with one exception. Many are explained via an equation as a simple offset from the epoch of the Julian day number, which is also extensively explained in the article. I don't know what else could be said about each, and I am familiar with most. The lone exception is noon 31 December 1899, which is actually the epoch of all ephemerides used during most of the twentieth century, through 1983. It was originally stated in Newcomb's Tables of the Sun as the beginning of 0 January 1900 because before 1925 the astronomical day started at noon, not midnight. Thus it is the beginning of the astronomical twentieth century which is appropriate for tables publish only five years earlier (1895) which were intended for use beginning in 1900. I'll add a few words about that to the article. — Joe Kress 00:03, 11 November 2006 (UTC)

Classically, 0 Jan 1900 was about a year before the beginning of the 20th century AD. One might clarify "astronomers' day" by explicitly indicating that it started 12 hours "late" by Winter time at Greenwich (the RN date, up to 1805, started 12 hours early, local time). 82.163.24.100 11:10, 20 February 2007 (UTC)

4713 BCE is the first year of the Julian Period, the origin of which is explained in the article already. The other years do not necessarily have any meaning, in and of themselves, but what you get when you perform the subtractions in the article. 1858 is simply what you get when you remove the first two digits of the current Julian day number. 1968 is what you get when you remove the first three digits (or it was between 1968 and 1995). 1899-12-31 is the last day of the 19th century, and the date of the standard epoch (at noon ET). 1601 was the first year of the first complete Gregorian cycle of 400 years. --Nike 00:11, 11 November 2006 (UTC)

The last day of the 19th century was 1900-12-31. 1899-12-31 was the lasy day of the 1800s.

Any interval of 400 years Gregorian is a cycle. By starting on (400*N)-03-01, Leap Days are simpler, occurring (or not) at multiples of 4, 100, 400 years into the cycle.

Excel, VBscript, etc., have a base of 1899-12-30 = Day 0, local time. I think that base should be nentioned, if only to clarify that it and the astronomers' nearby date are quite distinct concepts.

82.163.24.100 11:10, 20 February 2007 (UTC)

You are right, I was careless. I should have written that this was the last day of century 18 (in astronomical/ISO year numbering). This was an off-the-cuff remark I made several months ago, and does not appear in the article.

As for the ANSI date, I think that the wording in the article, itself, is clear, which is the important thing. It says that 1601 is the beginning of the cycle which ended with the year 2000, which is true either way. I seem to recall reading that complete Gregorian cycles are considered to end in years divisible by 400, just as Gregorian centuries end in years divisible by 100, but I don't have references handy, and it's not part of the article, so I see no point in debating the subject.

If you enter 0 into an Microsoft Excel for Windows date-formatted cell, it will display 1/0/1900. If you enter 1, it will display 1/1/1900. Other products may display 12/30/1899 and 12/31/1899, respectively. If you enter 60, Excel will display 2/29/1900, which did not exist in the Gregorian calendar. Other products might display 2/28/1900. Only after day 60 are the results consistent. The Excel serial date was actually copied from Lotus 1-2-3, so Lotus should get the credit, as well as the blame. There used to be a mention of Excel, and Lotus/Excel dates could be included under alternatives, I think. However, you need to be careful about describing how days 0-60 are displayed in different products, because there are differences. --Nike 23:57, 20 February 2007 (UTC)

In fact, it might be better if "alternatives" was a separate article (not with that name). Many of them are direct derivatives of Julian Days, i.e. HJD, RJD, MJD, TJD, DJD, CJD. Others are similar day-count systems, which may not be directly related, i.e. RD, Lilian, ANSI, Lotus/Excel. Unix dates are listed, even though they are not a day-count at all, but a count of seconds, so I'm not sure of the relevance. I do not know of a single term which is used for all of them. "Integer date" is sometimes used with COBOL, but does not fit those which have decimal fractions. Excel's are called "serial dates". "Julian date" seems to be used generically to cover various systems which do not use the Julian Period epoch. (See also INTEGRAL Julian Date starting 2000 January 1.0 TT.) Perhaps they could collectively be called "day-counts" or "decimal dates". --Nike 01:09, 21 February 2007 (UTC)

[edit] Julian date ParserFunctions in article?

The ParserFunctions used in this article won't necessarily display correctly unless the page is purged every few seconds. In particular, the non-rounded ParserFunction is a problem, because it can vary by up to about 1 with the real date - the rounded one will probably be updated often enough to stay accurate, since it only needs to be updated every 12 hours or so. Can we remove the non-rounded value please? It's a permanent factual inaccuracy, and the only way of noting that inaccuracy is a self-reference. Nihiltres 16:26, 8 December 2006 (UTC)

[edit] Possibly incorrect algorithm (Gregorian calendar from Julian day number)

I've tried to use this algorithm [5] to calculate gregorian calendar date from JD, and find it to be incorrect.

PHP code:

input.php :

<html>
<head>
<title><? print "Hello world!"; ?></title>
</head>
<body>
<form action = "result.php" method="get">
  JD: <input type="text" name="jd"/>
<input type="submit"/>
</body>
</html>

result.php :

<html>
<body>
<?php
$j = $jd + 32044;
$g = $j / 146097;
$dg = intval($j/146097);
$c = ($dg / 36524 + 1) * 3/4;
$dc = $dg - $c*36524;
$b = $dc/1461;
$db = intval($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;
$year = $y - 4800 + ($m + 2)/12;
$month = intval(($m + 2)/12) + 1;
$day = $d + 1;
?>
year: 
<?php print $year; ?>
month: 
<?php print $month; ?>
day: 
<?php print $day; ?>
</body>
</html>

—The preceding unsigned comment was added by Chesnok (talk • contribs) 22:28, 18 February 2007 (UTC).

You are not implementing the algorithm as it was written. For one thing, you are using intval wherever the algorithm calls for mod. In PHP, the modulus operator is %. Also, you are not using integer divisions, where the instructions clearly call for it, so you should be using intval wherever it says div, and not where it says mod. There may be other things I haven't noticed.

I do not think that all these conversion algorithms are really necessary in an encyclopedia article. We could just provide links to off-site references. See this JavaScript, for example. Most languages, including PHP, have time and date routines which make the process easier, so that complicated algorithms are not necessary. One option is to convert JD to Unix time, which is trivially easy, then use built-in functions to convert Unix time to a Gregorian date. The following should work in PHP, at least for the supported range:

date ("M j, Y", ($jd-2440587.5)*86400)

--Nike 09:28, 21 February 2007 (UTC)

[edit] Image from orbital sim

I am wondering how the image that was just added helps the article. It is simply an image of text reading "MJD 54075.8262" without any context. What is the point of this image? --Nike 07:51, 21 February 2007 (UTC)

[edit] Today is Monday, or Sunday?

I noticed that the article illustrates Julian day using the current date function. Good job!

Now at 09:35, Monday 12 March 2007 (UTC) the JDN is 2454171. The remainder of this value divided by 7 is 6, an integer expression for the day of the week with 0 representing Monday.

The moment I first view the article, I am puzzled by the last sentence that "0 representing Monday" while the sentence before it says that the "remainder of this value divided by 7 is 6". Today is Monday, but why the day of the week is 6, i.e. Sunday? It was after a few minutes that I realized that Julian day starts at noon. Here is a humble suggestion: Why don't we change the last sentence to denote that the integer expression for the day of the week starts from noon? --Joshua C hi e w 09:50, 12 March 2007 (UTC)

I do not understand the relevance of the day of week in this article at all. It's now mentioned several times in the article, and for what reason? Julian days do not even correspond with civil days, since they start at noon UT, so part of the day will be on Sunday and part on Monday. Sure, you can determine the day of week from the Julian day number, but this seems to be a trivial application. How often is the Julian day used for this purpose? I can agree with it being in the calculations section, but why both the first and second paragraphs? If it is being used somewhere, then it needs citations. Also, does anybody really use negative Julian days? If so, why? Also, it is not explained how negative fractions are handled, i.e. is -0.75 06:00 or 18:00? Again, where are the citations? Also, there are at least a couple of places where the "current time" is given, even though this is supposed to be a no-no on WP because of caching. This article seems messy and overlong. It should probably be split up. --Nike 08:06, 14 April 2007 (UTC)

[edit] Alternatives: Rata Die

Surely(?) Gregorian 0001 Jan 01 was a Monday; it was Julian 0001 Jan 01 that was a Saturday. —The preceding unsigned comment was added by 86.7.17.120 (talk) 10:43, 20 March 2007 (UTC).

[edit] Didn't quite get it right?

Firstly many thanks for the effort put in here. Was hoping to quickly grab an algorithm and knock up some code for my purposes. But alas, things not quite right. Can't see an obvious error on my part. Is there an obvious reason?

R code:

julday_jul <- function(day,mth,yr) {

   a <- floor((14-mth)/12)
   y <- yr+4800-a
   m <- mth+12*a-3
   julday <- day+floor((153*m+2)/5)+365*y+floor(y/4)-32083
   julday
 }

julday_greg <- function(day,mth,yr) {

   a <- floor((14-mth)/12)
   y <- yr+4800-a
   m <- mth+12*a-3
   julday <- day+floor((153*m+2)/5)+365*y+floor(y/4)-floor(y/100)-floor(y/400)-32045
   julday
 }

If I put in the values for 24th July, 2007, I'm told that it is JDN is 2454305, however these routines give:

> julday_jul(24,7,2007)

[1] 2454319

> julday_greg(24,7,2007)

[1] 2454272

I was looking at a weather record from 1859 and was out by 1 day in the length of the record when I used the routine for the Julian calender. If I considered the dates on 1/1/1900 and 1/3/1900 I get a 60 day difference, should this not be 59? In doing some further calculations I found that this was the only difference between the data I had and the calculations I obtained from above.

The comparison I made with the Gregorian calendar came up with only 364 days in 2000.

I also got some slightly contrary results with the routine doing the inverse calculations.

R code:

dmy <- function(julday) {

   j <- julday+32044
   g <- floor(j/146097)
   dg <- j %% 146097
   c <- floor((dg/36524+1)*3/4)
   dc <- dg-c*36524
   b <- floor(dc/1461)
   db <- dc %% 1461
   a <- floor((db/365+1)*3/4)
   da <- db-a*365
   y <- g*400+c*100+b*4+a
   m <- floor((da*5+308)/153-2)
   d <- floor(da-(m+4)*153/5)+122
   Y <- y-4800+floor((m+2)/12)
   M <- (m+2) %% 12+1
   D <- d+1
   list(D,M,Y)
 }

Using the JDN values for the 1st day of the year using the Julian calendar as given above i.e. julday_jul gave me 1st days of the year that oscillated between the 12th and 14th January through until 1901 after which the dates oscillated between the 13 and 15th. This increment would be due to the additional day in the year 1900.

I would be appreciative if the problems here, be it in my code or otherwise, be considered. I'll have another look later, if time permits, but clearly a lot of you know more about all of this than I and the differences might be something that can be immediately identified.

PS: Sorry for the total lack of Wiki skills, I haven't got that right either. First time, will need to work on this as well as my code....

Nsdave 08:02, 24 July 2007 (UTC)

You entered "floor(y/100)-floor(y/400)", but the article clearly says that it should be a plus, not a minus, so your code is off by twice the value of floor(y/400). But the external links are better resources for finding algorithms. It is not appropriate to be debugging code here. There are other forums for that. The standard C date/time library makes conversions much easier; just get the Unix time, divide by 86400 and add 2440587.5 for the Julian Date. --Nike JD 2454305.949

Sincere apologies for abusing the purpose of this discussion page, Nike, in doing what I did. I had a Julian Day to forget in many ways and thought there may have been a problem. Can this day be scrubbed from the calendar? The main error I ultimately didn't wasn't what you kindly pointed out, but rather I used the float routine in R and not the trunc command. I didn't wish to use another program because I needed to write some code of my own, hence the need of an algorithm. I have subsequently got it to work and in the interests of bowing out gracefully of the waste of time I may have created, I add the corrected code for determining the Gregorian date as a function of the Julian Day just in case somebody may want to use it.