Talk:Julian day/Archive 1

Solar Cycle[edit]

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)

And that the 28-year cycle occurs in the Gregorian Calendar, except where broken by a missing leap year. Noting that the 28-year cycle would degenerate if the length of the year were larger by exactly 4 + 7*N days, in the same way as the Gregorian week-day cycle is not 7*400 years. 82.163.24.100 (talk) 12:58, 10 September 2008 (UTC)[reply]

Rather than individual pages on individual cycles associsted with the Gregorian Calendar and its predecessors, would it not be better to have a single "Calendar Cycles" page in three main parts, one for ancient, one for secular and one for non-secular?

8, 15, 19 years
7 days, 4, 28, 400 years
532, 5700000, 39900000? years

http://www.merlyn.demon.co.uk/critdate.htm#OPs has a partial list. 82.163.24.100 (talk) 20:44, 27 September 2008 (UTC)[reply]

any Greenwich time[edit]

"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)

Alternative name[edit]

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)

Other epochs, etc.[edit]

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)

History[edit]

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.

But see [1]. 82.163.24.100 (talk) 18:47, 16 July 2008 (UTC)[reply]

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)[reply]

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)

Start of year[edit]

"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)[reply]

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)[reply]

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 [2] (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[3] 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)[reply]

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)[reply]

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)[reply]

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)[reply]

"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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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

Leap seconds[edit]

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)[reply]

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)[reply]

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).

—Preceding unsigned comment added by Verdy p (talk • contribs) 01:25, 15 May 2006

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)[reply]

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.

—Preceding unsigned comment added by Verdy p (talk • contribs) 01:25, 15 May 2006

I'm unable to decipher the above mess, or figure out which remarks should be attributed to which editor. However, it contains significant errors.

Universal Time is a somewhat generic term for mean solar time. In practice, it is found not through observations of the sun, but by observing sidereal time and using a formula to convert to mean solar time. During the 20th century observations showed that this was irregular both compared to atomic time, and the orbits of other solar system bodies such as the moon orbiting the earth. The two most popular variations are UT1, in which every day has exactly 86,400 seconds, but the length of the second is slightly irregular, or UTC, in which every second is as nearly the same length as a large group of atomic clocks can measure, but leap seconds are used to keep time UTC within 0.9 s of UT1.
Terrestrial time is defined in an abstract way, but is implemented by adding 32.184 s to International Atomic Time. TT has no leap seconds, and every day consists of 86,400 SI seconds. TT essentially has the same uses as TAI, but is defined with a constant difference so that there was no discontinuity in ephemeris calculations when the change from Ephemeris Time to TAI was made.
The laws of physics, which are used to perform emphemeris calculations, are expressed in the SI second. General relativity shows that time passes at different rates for different observers, depending on their relative motion and the gravity field surrounding each observer. Therefore other time scales are calculated which remove the influence of the earths gravitational field, rotation, or orbit. Geocentric Coordinate Time is used for calculations in the earth-moon system while Barycentric Coordinate Time is used for calculations of planetary orbits.
Any of these time scales could possibly be used as the underlying time for Julian dates. --Gerry Ashton (talk) 23:25, 28 August 2008 (UTC)[reply]

Inverse Calculation[edit]

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))[reply]

Wrong calculation formula?[edit]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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.

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

Algorithms used frequently in computer programming include:

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

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

HoCkster 18:09, 4 January 2006 (UTC)[reply]

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)[reply]

You're confused about the epoch - the gregorian calendar has only on dividable epoch - 400 years ( the year % 400). All you have to do is be able to find the number of leap years in that period, then multiply year/400 by 146097 (gregorian) 3 more than that for julian. The Gregorian calendar repeats every 400 years when using no extended leap year rules, the julian obviously every 4. I was trying to find the fastest algorithm for a computer programwhen I posted that, the epoch offset is arbitrary and it doesn't matter since the offset i(10,000) is divisible by 400. When posting algorithms integer division is ALWAYS presumed unless otherwise specified, as in some languages anything passed as an integer to a function (such as a year) which is declared as an integer will yield an integer unless cast as a floating point variable —Preceding unsigned comment added by 202.150.122.229 (talk) 10:11, 26 October 2008 (UTC)[reply]

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)[reply]

Any such algorithms should be accompanied by a clear statement of their range of validity, allowing for possible behaviour of div & mod. Also, when using a computer language, that language needs to be named. 82.163.24.100 (talk) 20:48, 29 September 2008 (UTC)[reply]

Gregorian date elements[edit]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Article length[edit]

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)[reply]

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)[reply]

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 2460439.4022106 - 2400000.5 = 60438.9022106.

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)[reply]

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)[reply]

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

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)[reply]

Fliegel & Van Flandern's algorithms[edit]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Chronological Julian Day (CJD)[edit]

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)[reply]

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)[reply]

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)[reply]

 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)[reply]

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)[reply]

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

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)[reply]

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.[4][5] --Nike 15:31, 14 February 2007 (UTC)[reply]

Start dates[edit]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Julian date ParserFunctions in article?[edit]

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)[reply]

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

I've tried to use this algorithm [6] 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).[reply]

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)[reply]

Image from orbital sim[edit]

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)[reply]

Today is Monday, or Sunday?[edit]

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)[reply]

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)[reply]

Alternatives: Rata Die[edit]

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).[reply]

Didn't quite get it right?[edit]

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)[reply]

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.

dmy <- function(julday) {

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

Cheers...

Nsdave 14:16, 24 July 2007 (UTC)[reply]

Universal time of Common Lisp[edit]

I wonder if it should be mentioned among the alternatives? Here is the definition: [7]. Basically it's the number of seconds since January 1, 1900. Grue 09:38, 23 December 2007 (UTC)[reply]

Wrong formula for weekdays[edit]

I suspect that the formula to calculate the weekdays, visible in edit mode, is wrong. Currently, it results in the following statement.

"Now at 20:18, Tuesday 12 August 2008 (UTC) the JDN is 2454692. The remainder of this value divided by 7 is 2, an integer expression for the day of the week with 0 representing Monday."

If today, Tuesday, is represented by a 2, then yesterday, Monday, must have been represented by a 1, because yesterday's JDN value is one less than today. This clashes with the last cited statement that Monday is represented by a 0. Tomeasy_{T C} 20:19, 12 August 2008 (UTC)[reply]

Although there is definitely a problem with the formula, I'm not sure how to correct it. The expression was added on 1 January 2007 by Dhaluza as ({{CURRENTJULIANDAY}}-0.5) round 0}}, but the sign was changed by an anonymous editor on 28 March 2008 to ({{CURRENTJULIANDAY}}+0.5) round 0}}. A disconnect appears to exist between the current time/date, which is midnight-to-midnight, and the JDN, which is noon-to-noon. So results may be correct or incorrect depending on the time of day. The solution may be to remove it from the article altogether as discussed above at Today is Monday, or Sunday?. — Joe Kress (talk) 00:30, 13 August 2008 (UTC)[reply]

I think I fixed it. After reading a bit into the matter, I think it is actually very easy. The return value of CURRENTJULIANDAY has to be stripped of its decimals, which is simply done by (X round 0). No +/- 0.5 is necessary at all. Let me know what you think. Tomeasy_{T C} 19:40, 14 August 2008 (UTC)[reply]

Sorry for my ignorance. I did not read carefully your post, so I missed to see that JDN counts from noon to noon. Consequently, my above post and the change in the article was wrong. Even worse for me, the correct solution was already given by you: 0.5 should be subtracted before rounding (not stripping)! I have implemented it now. Since you actually understood more than I about the JDN, I guess the reason you could not correct the article was that you do not understand the syntax used. I have prepared a set of examples for this in my sandbox. Tomeasy_{T C} 20:01, 14 August 2008 (UTC)[reply]

The overall result is simply wrong. All you have done via {{CURRENTJULIANDAY}}-0.5 round 0 is to correctly truncate the Julian date to obtain the Julian day number, which by definition is noon-to-noon. But that JDN has no relation whatsoever to the day of the week, which by definition is midnight-to-midnight. As long as {{CURRENTDATE}} includes the day of the week and the rest of the paragraph discusses obtaining the day of the week via the remainder of JDN divided by 7 (JDN mod 7), the result will be wrong. What is usually done is to apply the JDN of noon to the entire midnight-to-midnight day centered on that noon, for example in Calendrica. But this simplification requires that the Julian date before noon be rounded up via {{CURRENTJULIANDAY}} round 0 before taking the modulus. But then that noon JDN is not the true JDN calculated earlier, so the two results will disagree. — Joe Kress (talk) 05:20, 18 August 2008 (UTC)[reply]

I see two things: First, my edit from last week produces again wrong results, now in the morning hours. Second, you obviously understand much more of it than I. Thus, could you fix in whatever way appears appropriate to you? The current state of the article compromises the quality of wikipedia, as every reader (like I) will see immediately it is wrong. Unfortunately, fixing is more involved than I thought. Tomeasy_{T C} 06:44, 18 August 2008 (UTC)[reply]

I've corrected the day of the week by separating it from the standard JDN described in the first paragraph, and using {{CURRENTJULIANDAY}} round 0 to calculate the nearest noon JDN before taking the mod. I've also corrected two entries in the table. Hopefully that fixes all problems. — Joe Kress (talk) 22:22, 18 August 2008 (UTC)[reply]

I think the danger of trying to do current date calculations is that the primitive programming language used lacks a truncate function. Therefore, the truncate function must be approximated by subtracting 0.5 and then rounding. Whether a value such as 2454712.5 would round to 2454712 or 2454713 is anybody's guess, but with any luck, the fraction part of the current time will seldom be exactly 0.5.

Is it save to leave the table this way and hope future editors catch on to this trick, or would it be better to recompute the table for some recent date? --Gerry Ashton (talk) 21:01, 2 September 2008 (UTC)[reply]

Even though I said below that I don't have a strong opinion one way or the other, after I wrote that the date was "slightly erroneous", I discovered that I couldn't get the 'current' date to change with the recommended F5 or Ctrl F5 (in IE). However, when I checked it about 12 hours later it had changed without having been rebooted. Thus I am quite disappointed with the 'accuracy' of the 'current' calculation, so I now support the calculation of a recent fixed date. — Joe Kress (talk) 01:51, 3 September 2008 (UTC)[reply]

A suitable non-random recent fixed Julian Date is 2451550.09765 for the first mean new moon after J2000.0, as published by Jean Meeus, Astronomical Algorithms p. 319. This is not the true new moon because "mean" indicates that all perturbations by the Sun and planets are ignored. Although Meeus does say so, this is 2000 January 6 14:20:37 TT. — Joe Kress (talk) 04:03, 4 September 2008 (UTC)[reply]

How about Tuesday, June 8, 2004, about 6 AM Eastern Daylight Time: the transit of Venus was observed at the United States Naval Observatory. (That's J.D. 2453164.92.) --Gerry Ashton (talk) 04:37, 4 September 2008 (UTC)[reply]

AM and PM should not be used in an international medium. 82.163.24.100 (talk) 22:39, 8 September 2008 (UTC)[reply]

I suggest 1999-08-11 Wed 10:51.2 UT, the date of a Total Eclipse visible (total or partial) across Europe, including at Greenwich and at BIH Paris, with the UT at which the centre was at local apparent noon. MJD was 51401. If the Origin of Time ever needed recovery, it might be better done from Eclipses, distinguishable by their tracks and their central times. 82.163.24.100 (talk) 22:39, 8 September 2008 (UTC)[reply]

Your Julian date is inferred—it does not appear on the cited web page. Nor does any Julian date appear on the much more detailed USNO prediction page, "Transit of Venus, 2004" (PDF). (47.8KB). Nevertheless, mine is also deficient because it is not between midnight and noon, so cannot be used to illustrate that the JDN changes at noon. A Julian date that is between midnight and noon, has five significant digits after the decimal point, and has been published is the first mean March equinox after J2000.0, 2451623.80984 TT according to Jean Meeus, Astronomical Algorithms, page 166, which is 2000 March 20 7:26:10 TT (the latter date/time is unstated by Meeus). As before, "mean" indicates that this is the starting point when calculating the true equinox—sinusoidal perturbations by the other planets must still be added. — Joe Kress (talk) 04:50, 5 September 2008 (UTC)[reply]

I like your criteria; I picked a value between midnight and noon by happenstance. It would indeed be ideal to have a reliable source that had published both the civil date and time at Greenwich in the winter, and the JD. But my bigger concern is the calculation for all the different formats. I can find publications that clearly define MJD. I found the publication that gave the first definition of Lilian date (although IBM seems to have used it with their AS/400, eServer series i, and System i mainframes; who knows what extensions or changes might have been made). The rest do not have adequate references on the page. My gut feeling is that it isn't just a matter of going through the formality of finding a source for something that "everybody knows". When it comes to time, dates, and calendars, I'm reminded of my old neighborhood, which contained a Bear Trap Road. --Gerry Ashton (talk) 05:17, 5 September 2008 (UTC)[reply]

I was assuming that whatever Julian date is chosen would be appropriately modified for all the other formats, hence the MJD for the March 2000 equinox would be 51623.30984. This allows the same instant to be given in all formats so they can be compared with each other, which would not be possible if different sources giving different instants were used for each format. — Joe Kress (talk) 05:33, 5 September 2008 (UTC)[reply]

Meeus gives both the Julian date and the corresponding date/time which meet my criteria in a worked example: the new moon of February 1977 occurred at 2443192.65117 or 1977 February 18 3:37:41 TT (p.323). However, he refused to use the term "Julian date", stating that that meant a date in the Julian calendar, using instead Julian Ephemeris Days (JDE) (p.59). Instead of Ephemeris Time used from 1900 to 1983, Meeus noted that in 1984 both Barycentric Dynamical Time and Terrestrial Dynamical Time were implemented, but because the difference between them does not exceed 0.0017 seconds, he used a generic "Dynamical Time" (TD) (p.71). TDT was renamed TT in 1991. — Joe Kress (talk) 08:00, 5 September 2008 (UTC)[reply]

I never meant to suggest the times in the different examples should be different; they should all be representations of the same time. What I meant was we don't have references to explain how many of the other representations should be computed. --Gerry Ashton (talk) 15:31, 5 September 2008 (UTC)[reply]

ISO 8601:2004 3.2.1 gives 20 May 1875 as the reference point of the Gregorian Calendar - noon of that day, at a stipulated place, would be appropriate for an example. 82.163.24.100 (talk) 22:39, 8 September 2008 (UTC)[reply]

There is authority for JD 0.0 being proleptic Gregorian -4713-11-24 12:00:00 UTC; the JD for any multiple of 400 Gregorian years thereafter is easily calculated by adding that multiple of 400*365.2425 = 146097. From 2087-11-24 one can move back in multiples of 28 quasi-Julian years equally easily (28*365.25 = 10227), to 2003-11-24. 17*146097 - 3*10227 = 2452968. Giving a checkable calculation is better than citing a reference which might include a typo. Alternatively, use a multiple of 28 Julian years from -4712-01-01, and adjust by the known J-G difference, easily calculated from the Calendar Act. 82.163.24.100 (talk) 22:39, 8 September 2008 (UTC)[reply]

Real Time Calculations within the Article[edit]

REMOVE all real-time calculations from the main text of the page; they are evidently unreliable, and even if correct would add no true value. Give there the JD for Gregorian 2000-01-01 noon UTC, which is sufficient to indicate the general size.

If there remains a wish for real-time display, then put it in a separate ghetto section of the Article. I know nothing about how Wiki pages calculate such.

The right answers are at [8] (Reykjavik, always GMT), to which I suggest adding a link (unless anywhere else uses permanent UTC/GMT, and is deemed more likely to continue doing so).

82.163.24.100 (talk) 12:52, 29 August 2008 (UTC)[reply]

Sorry to disappoint you, but your cited source is wrong regarding the name. What it calls the Julian day number is really the Julian date, which is the integer Julian day number plus the fractional day since the preceding noon UT. Otherwise, I see no great error in Wikipedia's calculation, although it is known that time calculations on Wikipedia can be slightly erroneous due to caching. I do not have a strong opinion regarding keeping them within the article. I am considering rewriting the lead section because it contains way too much information for the lead section of Wikipedia articles, which would include moving the 'real-time' calculations to a sub-section. — Joe Kress (talk) 23:12, 29 August 2008 (UTC)[reply]

The name is of little importance; in the outside world Day and Date are frequently used indiscriminately as the context generally suffices. It is the actual number which matters. 82.163.24.100 (talk) 22:04, 4 October 2008 (UTC)[reply]

http://en.wikipedia.org/wiki/Help:Variable includes Because of the way MediaWiki and most browsers cache HTML pages, time variables which change more often than once a day will typically show the time the page was last cached, rather than the current time.. A similar statement should be included in the "real-time" part. I've edited http://en.wikipedia.org/wiki/Help_talk:Variable including suggestion of DAYCOUNT variables which would of course simplify calculation of JD. 82.163.24.100 (talk) 16:40, 9 September 2008 (UTC)[reply]

Article today had Now, at 21:16, Saturday October 4 2008 (UTC) the JDN is 2454744 and a similar statement soon after. To mitigate the cacheing problem, one can change that form to At 21:16, Saturday October 4 2008 (UTC) the JDN was 2454744 and the other one correspondingly. And equalise commas! 82.163.24.100 (talk) 22:04, 4 October 2008 (UTC)[reply]

Modified Julian Day[edit]

Article has, in "Alternatives" under the Table, "The Modified Julian Day is found by rounding downward". No; that's not right. Rounding what, anyway?

In that table, CJD line, column 3, typo, JDN should evidently be CJD. Column 5, misuse of 'time zone' - UK's GMT and BST are in the same time zone but differ by an hour.

CJD is essentially NOT time zone or offset specific; CJD 0.5 refers to that noon which passed through the Greenwich Zone at noon on BC 4713-01-01 - it lasted for a little over 24 hours, with present time rules.

Agreed : JD is calculated from 12:00 UTC on that date. MJD is counted from 00:00 UTC, 2400000.5 days later.

But CJD and CMJD are calculated from 00:00 Local Civil Time. It is confusing to give a simple equation linking them that applies only for a particular LCT offset of zero. If equations are given, they need a variable term for LCT Offset.

I suggest two tables (or a two-sectioned one), one for the UTC-based values and one for the LCT-based ones.

I see no real need to include the Numbers in the Table(s), if they are all integers given by truncating the fractional part of the real Date, and that is clearly said nearby.

82.163.24.100 (talk) 22:44, 27 September 2008 (UTC)[reply]

CJD[edit]

I suggest Chronological Julian Date be deleted altogether, since as far as I can tell, it was suggested by Peter Meyer and not adopted by any authority or standards body. --Gerry Ashton (talk) 23:15, 27 September 2008 (UTC)[reply]

I think that we will have no difficulty in agreeing that if CJD and CMJD are present, then the related information must be clear and correct.

It is well understood that Easter Sunday is on the same day and date worldwide, although it is almost finished in New Zealand before it starts in Hawaii; and likewise for any other Gregorian civil date. The corresponding daycount is computationally useful and deserves a name, CJD being suitable; and CMJD has fewer digits.

As a compromise, how about a paragraph saying (approximately) "For a count of local dates from Julian BC 4713-01-01 = Day Zero, Chronological Julian Date (CJD) can be used."?

If CJD is removed from this Article, the entry in the CJD disambiguation page should be removed; otherwise, it should be corrected.

82.163.24.100 (talk) 18:33, 28 September 2008 (UTC)[reply]

I prefer to delete it. If we do keep it, I suggest we start with the definition given by its creator, Peter Meyer:

The chronological Julian date at a particular timezone is the number of days and fraction of a day which have elapsed since midnight in that timezone at the start of -4712-01-01 in the proleptic Julian Calendar.

Suggestion, if that approach be taken : The Chronological Julian Date (CJD) of an event is the number of days and the fraction of a day which have elapsed since the start at that location of -4712-01-01 in the proleptic Julian Calendar. I suspect the integer version is much more likely to be used. 82.163.24.100 (talk) 19:52, 29 September 2008 (UTC) ... insert "clock" before "day" to allow for days of other than 24 hours - or "apparent" before "fraction". 82.163.24.100 (talk) 20:18, 30 September 2008 (UTC)[reply]

We might consider altering it a bit to use a more suitable word or phrase than timezone, or leave it just as it is and push that problem onto whoever wants to use the definition.

The reason I prefer to delete it is that I don't think it is the role of Wikipedia to promote a little-used neologism. --Gerry Ashton (talk) 20:25, 28 September 2008 (UTC)[reply]

On the other hand, Wiki ought to serve those who, for whatever reason, seek in the JD page information on CJD. 82.163.24.100 (talk) 19:52, 29 September 2008 (UTC)[reply]

The article currently has, near the top, "If the Julian date of noon is applied to the entire midnight-to-midnight civil day centered on that noon, ...". That is only possible ("centered") if the observer is chronologically at Greenwich. If it is applied to the whole civil day which at Greenwich is so centred, the whole civil day as it travels from New Zealand to Hawaii, then that is a Chronological Julian Day Number - this showing the usefulness and relevance of CJD. 82.163.24.100 (talk) 21:08, 8 October 2008 (UTC)[reply]

Expression of Epochs[edit]

In the alternatives section, the first three entries use the proleptic Julian calendar and the BC notation. Despite this, they are expressed in a format that looks like ISO-8601. However ISO-8601 does not use BC notation (it uses negative numbers, and is "one out" from BC because there is a year 0000); and it does not use the proleptic Julian calendar (the proleptic Gregorian calendar can be used if agreed). Given that all other epoch dates use true ISO 8601, this seems inconsistent.

Another inconsistency is that most entries give the true date of the start of the epoch, i.e. "Day zero". But three of the entries give "Day 1" instead. —Preceding unsigned comment added by TomH (talk • contribs) 19:18, 6 October 2008 (UTC)[reply]

You have a valid concern regarding the BC entries. But three sources explicitly state that their epochal day was a day 1, not a day 0. — Joe Kress (talk) 00:06, 7 October 2008 (UTC)[reply]

Time Scale[edit]

The way I read IAU Bulletin 81, The preferred time scale for Julian Date is Terrestrial Time. I think that the article should reflect this fact. I would like to replace the first two paragraphs of the article with paragraphs numbered 1. and 2. as extracted below. from IAU IB81, but I don't know how to cite sources in Wikipedia and from looking over the help files it looks like that is more than I want to try to figure out at this time. If somebody wants to do this, then please do. Otherwise, comments are appreciated.

IAU / INFORMATION BULLETIN No 81[9]

RESOLUTION B1 January 1998

ON THE USE OF JULIAN DATES

The following definitions are recommended

1. Julian day number (JDN) The Julian day number associated with the solar day is the number assigned to a day in a continuous count of days beginning with the Julian day number 0 assigned to the day starting at Greenwich mean noon on 1 January 4713 BC, Julian proleptic calendar -4712.

2. Julian Date (JD) The Julian Date (JD) of any instant is the Julian day number for the preceding noon plus the fraction of the day since that instant. A Julian Date begins at 12h 0m 0s UT and is composed of 86400 seconds. To determine time intervals in a uniform time system it is necessary to express the JD in a uniform time scale. For that purpose 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). It should be noted that time intervals calculated from differences of Julian Dates specified in non-uniform time scales, such as UTC, may need to be corrected for changes in time scales (e.g. leap seconds).

An instant in time known in UTC can be converted to Terrestrial Time if such precision is required.
—Preceding unsigned comment added by Alexselkirk1704 (talk • contribs) 16:30, 11 October 2008

"IAU IB81" (PDF). (424KB) Resolution B1 on the use of Julian dates (p.22) or IAU 1997 Resolution B1 on the use of Julian dates only recommends TT if a uniform time scale is required. For general purposes it recommends UT, where UT1 or UTC should be specified if precision is needed. (The IERS version deleted "UT" immediately after 12h 0m 0s.) Sign your comment with four tildes, ~~~~, which Wikipedia software automatically replaces with your Username and time/date.— Joe Kress (talk) 03:43, 12 October 2008 (UTC)[reply]

Alright then, JD is generally (casually?) expressed in UT. The options we have for UT are UT1 and UTC. So then, what does it mean "since January 1, 4713 BC Greenwich noon"? Greenwich noon as expressed in UT1 or UTC? Which one? Neither of these apply to the year 4713 BCE. UT1 does not apply because we do not have the IERS EOP for that date. UTC does not apply because UTC includes leap seconds and there is insufficient data to determine proleptic leap seconds back to that date. I suppose that a reasonable guess of leap seconds could be made, but JD is a very precise time scale. Is a reasonable guess good enough? JD is a constant time scale, as is TAI, or in this case TT. January 1, 4713, Greenwich noon TT could be determined precisely. The IAU is right when they say that JD should be expressed in TT and they should not be so indecisive as to allow JD to be expressed in an inconstant scale such as UT1 or a discontinuous scale such as UTC.

Alexselkirk1704 (talk) 17:45, 12 August 2009 (UTC)[reply]

If we neglect differences of a few minutes, TT = UT in the late 20th century according to the official tabulated values of TAI-UTC, and according to the practical definition that TT = TAI + 32.184s. So any errors due to poor knowledge of the difference between TT and UT in the distant past will occur in the past, not in the present. --Jc3s5h (talk) 18:14, 12 August 2009 (UTC)[reply]

All time scales were "proleptic" in 4713 BC, that is, 4713 BC was long before they were invented. All options listed, TT, UT1 and UTC, and TAI as well, refer to the meridian through Greenwich, England, which did not exist in any form before 1678. Hence any such time scale must be projected back in time. Terrestrial Time is used whenever a uniform time scale is needed, for example, when solar system dynamics are calculated. This includes determining the position of one solar system body, like Earth, with respect to other solar system bodies, like the Moon or Sun. This is needed to determine whether lunar and solar eclipses will occur on Earth. Other uses include long term stability of the solar system. Laskar and others have recently determined [10] that in a few billion years, but before the Sun becomes a red giant, the inner solar system will become quite chaotic, with small but non-zero chances that one planet will collide with another. Far from the present (1955–2009), TT is assumed to be the independent variable of time in celestial mechanics when either analog equations, such as VSOP by the Paris Observatory, or digital time steps, such as DE406 by the Jet Propulsion Laboratory are used. TT can neither be rigorously nor independently determined far from the present. Even so, relativity, solar mass loss, acceleration of the Moon, aberration, light-time, etc. are independently included.

But whenever the visibility of these events is to be determined from some place on Earth, then the non-uniform time scale of Universal Time must be used. Converting a date in one calendar into another requires the visibility of the Sun (for solar calendars like the Gregorian and Iranian) or requires the visibility of both the Sun and Moon (for a lunar calendar like the Islamic or for lunisolar calendars like the Hindu or Chinese) relative to some place on Earth. Terrestrial Time cannot be used because the non-uniform rotation of the Earth relative to either the Sun or Moon is essential. Although TT must be used to determine whether a solar eclipse will occur, UT must be used to determine where and when it will occur on Earth, so for solar eclipses, both TT and UT must be used. The relationship between these time scales is ΔT, which can only be estimated via a parabolic function before the telescopic era (<1623) and beyond about a decade after the current year. I suspect that "general" in the IAU recommendation refers to the time that current events are recorded, when either UT1 or UTC are available. Of course, the IAU is only concerned with astronomical uses—it is not interested in calendar conversion, even though both use Julian days. So UT and TT each serves its own purpose. The more precise versions of UT1, UTC and TAI are useless far from the present (1955–2009). — Joe Kress (talk) 19:26, 12 August 2009 (UTC)[reply]