This is the
talk page for discussing improvements to the
Julian day article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives: 1, 2, 3, 4, 5Auto-archiving period: 91 days |
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||
|
This article links to one or more target anchors that no longer exist.
Please help fix the broken anchors. You can remove this template after fixing the problems. |
Reporting errors |
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)
Add a list of reference Julian day values with their gregorian calendar corresponding value. We need reliable sources to confirm each value reported.
That list could be used in unit tests for implementers of the algorithm.
Olivier Mengué | ⇄ Olivier Mengué | ⇄ 12:10, 14 June 2023 (UTC)
@
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)
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.
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)
Count of seconds, excluding leap seconds [Footnote omitted.]
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 must disagree. See the Unix time article, "Leap seconds" section. I'm copying the second table:
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)
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)
This is the
talk page for discussing improvements to the
Julian day article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives: 1, 2, 3, 4, 5Auto-archiving period: 91 days |
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||
|
This article links to one or more target anchors that no longer exist.
Please help fix the broken anchors. You can remove this template after fixing the problems. |
Reporting errors |
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)
Add a list of reference Julian day values with their gregorian calendar corresponding value. We need reliable sources to confirm each value reported.
That list could be used in unit tests for implementers of the algorithm.
Olivier Mengué | ⇄ Olivier Mengué | ⇄ 12:10, 14 June 2023 (UTC)
@
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)
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.
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)
Count of seconds, excluding leap seconds [Footnote omitted.]
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 must disagree. See the Unix time article, "Leap seconds" section. I'm copying the second table:
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)
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)