Jump to content

Talk:Julian day

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Irrelevant date/time scales

[edit]

The table of time scales under Variants includes some which, while interesting, are completely unrelated to Julian day (the subject of this article) and should be removed. In particular, Mars Sol Date, Unix time, and .NET DateTime are not even counts of (Earth) days, which is fundamental to the concept of JD. Include See also references to these other time scales if you like, but please do not pollute this table with them. Doug Ewell (talk) 21:37, 16 July 2021 (UTC)[reply]

Makes sense to me. WP:BEBOLD and remove them, see if anyone provides a convincing reason to reinstate. --John Maynard Friedman (talk) 22:42, 16 July 2021 (UTC)[reply]
OK, I agree about removing ones for Mars, but the others are related to JD in that they continuously increase. That is, they are scaled and offset from JD. This helps those converting to/from JD, using those systems, to get it right. Gah4 (talk) 22:36, 20 October 2021 (UTC)[reply]
I disagree that similar time scales like Unix time should be removed. Both MJD and Unix time are commonly used in logs, for instance, and it is therefore useful to know how to convert between the two. In fact before I took a look at this Talk page, my main use of this page was to figure out a) what MJD was, and once I knew that b) figure out how it relates to other time scales (Unix time in particular). Since Unix time is so ubiquitous, it seems reasonable to provide information relating the two time scales in this article. Akblakney (talk) 23:21, 27 December 2021 (UTC)[reply]
They could at least be moved to a second table, one that does not purport to contain “variants” of JD, but rather “other time scales.”
I’m not opposed to mentioning these time scales in the JD article, only to calling them “variants of JD” when they are nothing of the sort, any more than, say, the Maya Long Count is. Doug Ewell (talk) 20:52, 15 August 2023 (UTC)[reply]
I agree that some of the entries are not really appropriate to be listed as “variants” because they are just related counts, but they are informative regardless. However, I added the spreadsheet date introduced by Lotus 1-2-3 today, which got reverted. I think it has way more reason to be featured than, for instance, the Mars day count. — Christoph Päper 16:57, 31 January 2024 (UTC)[reply]
Most or all of the other time scales listed are a simple offset from JD, possibly with the complication that some are Universal Time and some are local time. But the Lotus 123 and Microsoft Excel for Windows time scale contains an error, so it would be necessary to explain the error. Do we want to get that far into the weeds for this article? Jc3s5h (talk) 17:29, 31 January 2024 (UTC)[reply]

Cycles

[edit]

@AstroLynx: I can understand why Ricercar a6 thought that By inspecting a 532-year Paschal cycle with 19 solar cycles (each year numbered 1–28) and 28 lunar cycles (each year numbered 1–19), was wrong. 19 cycles numbered up to 28 looks rather odd. If it is correct, then it needs an explanation? --𝕁𝕄𝔽 (talk) 20:53, 20 January 2024 (UTC)[reply]

I do not have access to the sources that support the passage in the article, I think what it's trying to say is that Scaliger got his hands on some paticular paper copy of a 532-year Paschal cycle, which contained 19 solar cycles, each of 28 years (19 × 28 = 532). Likewise the paper contained 28 lunar cycles of 19 years each. Scaliger made certain conclusions by looking at this paper.
Richards wrote
  • Richards, E. G. (2013). "Calendars". In Urban, Sean E.; P. Kenneth, Seidelmann (eds.). Explanatory Supplement to the Astronomical Almanac (3 ed.). Mill Valley, CA: Univ Science Books. ISBN 1-891389-85-8.
On page 591 he wrote a shorter, less confusing explanation:

In the sixteenth century, Joseph Justus Scaliger (1540-1609) tried to resolve the patchwork of historical eras by dating every event according to a single system (Scaliger 1583). Instead of introducing negative year counts, he sought an initial epoch before any historical record. His approach utilized three calendrical cycles: the 28-year solar cycle (the period after which weekdays and calendar dates repeat in the Julian calendar), the nineteen-7ear cycle of golden numbers (the period after which the Moon's phases approximately repeat on the same calendar dates), and the fifteen-year indiction cycle (the Roman tax cycle).

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

Perhaps our explanation should be more like Richard's. Jc3s5h (talk) 22:39, 20 January 2024 (UTC)[reply]
19 solar cycles, each of 28 years straight away makes a lot more sense. Yes, Richard's text is a lot better but maybe there is a succinct way to express it? 𝕁𝕄𝔽 (talk) 00:13, 21 January 2024 (UTC)[reply]
I've had a go, feel free to revise. I suppose it should have been obvious what was intended from the preceding text that describes 28-year solar cycles and 19-year lunar cycles, but a little reminder does no harm. 𝕁𝕄𝔽 (talk) 00:21, 21 January 2024 (UTC)[reply]

Conversions wrong?

[edit]

Since the MJD is based on UT and therefore able to drift with respect to unix time, I do not think that the conversion between MJD and unix time is correct. A static linear conversion cannot account for the drift. Fritut08 (talk) 07:06, 12 June 2024 (UTC)[reply]

I think the chief problem is what it says in the "Notes" column,

Count of seconds, excluding leap seconds [Footnote omitted.]

As I understand it, the formula for converting from wall clock time at Greenwich to Unix time does not allow for the second value to be "60", but also does not make allowance for the fact that the wall clock is set to UTC; that is the wall clock agrees with UTC except right after a leap second, until someone manually adjusts the clock to allow for the leap second that occurred. Since UTC is within 0.9 s of UT1, unix time is within 0.9 s of UT1 except perhaps near a leap second.
See https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_14 ¶ 4.14.
@Adhemar: It appears Adhemar added the phrase "excluding leap seconds". Jc3s5h (talk) 14:24, 12 June 2024 (UTC)[reply]
When the difference between UTC and TAI matters, it should be so indicated. Cf. Explanatory Supplement to the Astronomical Almanac (1992), section 1.252. AstroLynx (talk) 15:28, 12 June 2024 (UTC)[reply]
The passage in Explanatory Supplement to the Astronomical Almanac is only about Julian date, not Unix time. Unix time can't fully obey UTC because it is defined in terms of broken-down time. It's installation-defined whether a minute can sometimes contain 59 or 61 seconds. But once the minute that contained the unusual number of seconds is in the past, the minute is treated as comprising 60 seconds, and the day that contained the leap second is treated as comprising 86,400 seconds. Jc3s5h (talk) 16:00, 12 June 2024 (UTC)[reply]
Extending my comment, the Julian day, when not an integer, is not fully defined for UTC, because there is no single document that everyone agrees with that specified what to do with a leap second. So the problem isn't just Unix times, it's all the time scales mentioned in the article. Jc3s5h (talk) 12:38, 13 June 2024 (UTC)[reply]
I think POSIX time is generally agreed on? I don't think it is "installation-defined", POSIX is a standard and pretty much everyone who's anyone obeys it. It is true that it doesn't handle leap seconds well, and there are some workarounds like smeared leap seconds, but for the most part it seems people are happy to just ignore the leap seconds like the POSIX standard specifies. Like in the Unix time article, "Unix time is currently defined as the number of non-leap seconds which have passed since 00:00:00 UTC on Thursday, 1 January 1970." I guess strictly speaking it is not a timescale by itself but if you add an "in leap second" flag, like is available as a separate call to NTP in most APIs, then it is well-defined. Mathnerd314159 (talk) 01:32, 14 June 2024 (UTC)[reply]
Please see https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_14 which says some things about POSIX time are implementation defined. It does say to use UTC. A few quotes:

The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified.

How any changes to the value of seconds since the Epoch are made to align to a desired relationship with the current actual time is implementation-defined. As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds.

I also argue that "just ignore leap seconds" isn't a clear description of how to implement unix time, even if you decide to follow POSIX and follow UTC.Jc3s5h (talk) 09:51, 14 June 2024 (UTC)[reply]
That stuff is about clocks not being guaranteed to be accurate. The only thing that is implementation-defined is where the UTC value comes from. It doesn't affect the timescale - the conversion from UTC to POSIX is specified precisely, that's the formula. Mathnerd314159 (talk) 14:00, 14 June 2024 (UTC)[reply]

I must disagree. See the Unix time article, "Leap seconds" section. I'm copying the second table:

Unix time across midnight into 1 January 1999 (positive leap second)
TAI (1 January 1999) UTC (31 December 1998 to 1 January 1999) Unix time
1999-01-01T00:00:29.75 1998-12-31T23:59:58.75 915148798.75
1999-01-01T00:00:30.00 1998-12-31T23:59:59.00 915148799.00
1999-01-01T00:00:30.25 1998-12-31T23:59:59.25 915148799.25
1999-01-01T00:00:30.50 1998-12-31T23:59:59.50 915148799.50
1999-01-01T00:00:30.75 1998-12-31T23:59:59.75 915148799.75
1999-01-01T00:00:31.00 1998-12-31T23:59:60.00 915148800.00
1999-01-01T00:00:31.25 1998-12-31T23:59:60.25 915148800.25
1999-01-01T00:00:31.50 1998-12-31T23:59:60.50 915148800.50
1999-01-01T00:00:31.75 1998-12-31T23:59:60.75 915148800.75
1999-01-01T00:00:32.00 1999-01-01T00:00:00.00 915148800.00
1999-01-01T00:00:32.25 1999-01-01T00:00:00.25 915148800.25
1999-01-01T00:00:32.50 1999-01-01T00:00:00.50 915148800.50
1999-01-01T00:00:32.75 1999-01-01T00:00:00.75 915148800.75
1999-01-01T00:00:33.00 1999-01-01T00:00:01.00 915148801.00
1999-01-01T00:00:33.25 1999-01-01T00:00:01.25 915148801.25

Just before the end of 1998 leap second, Unix time is 915148800.00. The table shows the Unix time increasing during the leap second, with the time ending in 800.25, 800.5, and finally 800.75. Then at the first instant of 1999 the time snaps back so it ends in 800.00. Or if you only consider integer number of seconds, 915148800 occurs twice. But this behavior is not defined in POSIX; another implementation might just freeze the clock at 915148800.00 during the leap second. Jc3s5h (talk) 15:55, 14 June 2024 (UTC)[reply]

The POSIX spec requires all the inputs to the formula to be integers. But our article does not mention this limitation. So our article is not fully correct. Jc3s5h (talk) 16:13, 14 June 2024 (UTC)[reply]

Greg. Calendar to Julian Day Number wrong?

[edit]

I didn't dig into details, but it looks like the conversion from Greg. Calendar to JDN is wrong. "2034-02-28" yields the JDN "2464022", but so does "2034-03-01". I personally switched to E.G. Richards Chapter 15 (15.11) to calculate the JDN which works for all ranges I tested (roughly year -32000 to +32000) 81.217.6.16 (talk) 23:50, 28 December 2024 (UTC)[reply]

Are you talking about the formula at Julian day#Converting Gregorian calendar date to Julian Day Number? And you are saying that applying it to 2034-03-01 gives 2464022 whereas it should be 2464023? It's tricky applying that formula. {{extract}} confirms the answer: {{extract|2034-03-01|show=juliandate}} → 2464023. Johnuniq (talk) 00:41, 29 December 2024 (UTC)[reply]
There have been many complaints about the formula being wrong, and it always turns out the person complaining had not done integer division correctly. Jc3s5h (talk) 05:05, 29 December 2024 (UTC)[reply]
Is there a formula that doesn't depend on integer division? Maybe using floor or something? Mathnerd314159 (talk) 20:00, 29 December 2024 (UTC)[reply]
The main alternative source of algorithms that comes to my mind is Calendrical Calculations. But that is in Lisp, and I promise you, you don't want to try to put a Lisp algorithm in Wikipedia. Especially since all the algorithms in Calendrical Calculations are split into itty-bitty pieces and you'd have to put a whole bunch of algorithms in the article. Jc3s5h (talk) 15:48, 30 December 2024 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Julian_day&oldid=1266206019"