WikiProject Time		TimeWikipedia:WikiProject TimeTemplate:WikiProject TimeTime articles
Time portal v • d • e This article is within the scope of WikiProject Time, a collaborative effort to improve the coverage of Time on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.  ???  This article has not yet received a rating on the project's quality scale.  ???  This article has not yet received a rating on the project's importance scale. To-do List: Here are some tasks you can do: Expand: Timeline Other: Vital Articles The Wikipedia 1.0 Editorial team identified the following articles relating to Time as Vital: "for which Wikipedia should have a corresponding high-quality article, and ideally a featured article." Those marked with this icon: are also considered to be Core articles, "one of the core set of articles every encyclopedia should have." Their quality-scale rating as of February 2008 is listed alongside each: Calendar - B Clock - B Day - B History - B Month - B Second - B Time - B Week - B Year - Start Any help in improving these articles would not only further the efforts of WikiProject Time, but Wikipedia overall.

Archive 1

[edit] Time Scale

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[1]

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 IB81PDF (424KB) Resolution B1 on the use of Julian dates (p.22) or IAU 1997 Resolution B1 on the use of Julian dates only reccommends TT if a uniform time scale is required. For general purposes it reccommends 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)

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)

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)

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

[edit] Contradiction between Template:JULIANDAY and Julian day#Calculation

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

[edit] .NET DateTime

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

[edit] Oct 5 1582 - bug in some JDN calculators

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

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

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

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

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

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

[edit] Invalid edit

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

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

[edit] Gregorian to Julian Day conversion Disputed (Again)

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

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

The results of running this program are:

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

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

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

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

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

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

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

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

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

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

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

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

[edit] Algorithm for converting JDN to Julian-Calendar Date?

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

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

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

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

 sub JDNtoJulianDate (JDN, Y, M, D) '   --------------- '   Adapted from: http://dev.remotenetworktechnology.com/wsh/jdn.htm '   Similar to the Fliegel & Van Flandern method for Gregorian dates. '   Language: PowerBasic. (The symbol \ denotes an integer division.)       Local J, K, L, N, I       J = JDN + 1402     K = (J - 1) \ 1461     L = J - 1461 * K     N = ((L - 1) \ 365) - (L \ 1461)     I = L - 365 * N + 30     J = (80 * I) \ 2447     D = I - ((2447 * J) \ 80)     I = (J \ 11)     M = J + 2 - 12 * I     Y = 4 * K + N + I - 4716 end sub   '  JDNtoJulianDate  --------------------------------------- 

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