Preben Norager wrote: >We now know that the julian period is not all of history,
Newcomb didn't claim that it is. It is actually the case that the Julian Period covers all of *recorded* history (i.e., history that was written down at the time), and there is some small convenience in that fact. But in your quotation Newcomb describes JDs as "the number of days ... *before or* after this epoch" (my emphasis). He envisions negative JDs, and we have no difficulty extending numbers in that direction as far as we care to go. The JD system thus does cover all of history. For that matter, the Julian Period will end in another 1250 years or so, but JDs extend forward past that point too. His main claim there is that the system is "continuous through all history". Continuity is a noted feature of the real numbers. > and we also know >that the mean solar day is not an expression of the greatest precision. True. In that role, mean solar time (Universal Time, UT) has been supplanted by Terrestrial Time (TT), Barycentric Coordinate Time (TCB), and other modern time scales. >I don't understand why science and astronomy still uses JD and MJD. The original reasons for using them still hold. Times on the newer time scales have always been expressed in terms of JD/MJD, by virtue of the transferance from UT to Ephemeris Time (ET), and thence to its relativistically-sound successors TT et al. On any of these time scales, the continuity, uniformity, and simplicity of a real-number linear count remain compelling features. Hypothetically, if the historical transfer of JD usage had not occurred, then practicality would require that we invent some equivalent linear count for the newer time scales. If there is any time scale that is an exception to the utility of JD, then it is UTC, by virture of its leaps. (Either the present leap seconds or the pre-1972 smaller leaps.) As discussed a few days ago on another thread, the irregularly non-uniform lengths of UTC days, as judged by UTC itself, causes some difficulty in reducing a UTC time to a scalar count. The resulting count is not continuous. The discontinuous count is in fact used for some purposes anyway. But the demands of practicality that lead one to use JD for UT1 instead push one towards an integer+real two-part count, such as (MJDN, seconds-since-midnight), for UTC. > I don't understand why science and >astronomy still uses julian calendar days, and not days of the proleptic >gregorian calendar. It depends on what one wants to concentrate upon. The Gregorian calendar is convenient in placing dates relative to the cycle of seasons. (It's not very precise in doing so; we can specify solar longitude if we're really interested in that.) Often the seasons would just be a distraction, so one would prefer to avoid specifying that. If there's no strong desire either way on that issue, then the simplicity and uniformity of JD are attractive features. By the way, there's a problem with your phrasing here around "Julian calendar days". You're referring to the linear day count systems such as Julian Date, but that phrase makes it look as though you're referring to the Julian calendar. That's a very different beast, the immediate predecessor of the Gregorian calendar, and bearing a strong resemblance to it. > With a simple computer program it is easy to compute >the exact fraction of days between two times in the proleptic gregorian >calendar, Requiring dates to be put through a computer program in order to properly understand them is still detrimental to comprehension. It will remain so as long as the computer program is not neurologically embedded. This works both ways, of course: JD is a poor way to describe historical events to the general public, just as the Gregorian calendar is a poor way to describe orbital events in a technical context. One must have due regard to the intended audience. But no matter how readily available a compuation is, the JD concept remains essential. Those calendar computation programs generally work by converting to JD or something equivalent underneath. Any computation of things happening over time is likely to want to describe time in a linear manner, at least as an internal variable. Anyone working closely with this kind of algorithm needs to work in a linear time variable. Astronomers do this sort of thing quite a lot. > and for the outreach to the general >public, I think it would be good for science and astronomy, to use the >gregorian calendar which the general public understands. In outreach contexts, sure, there's good reason to use the calendar that the target audience is already familiar with. But that's not a reason to compromise the precision or comprehensibility of communications from astronomer to astronomer. >I think my argument here for the civil and scientific use of the Gregorian >calendar does have something to do with the choice of underlying time >scale. The general public will never understand leap seconds, and I think >the general public shall have a time and a calendar they understand. You're making two parallel arguments here: for the use of the Gregorian calendar, and for the use of TAI-like days. The two do not support each other. The argument for the use of the Gregorian calendar is totally independent of the choice of time scale. The argument that you make for the use of TAI-like days is considerably weaker than the argument relating to the calendar. The general public has limited understanding of leap seconds, true, but it also has limited understanding of `days' that don't correspond to the motion of the sun in the sky. There's no corresponding problem for the argument about the calendar. You're welcome to develop both of these public-understanding arguments, but you'll do better treating them separately. The details of the two arguments are quite different. Each of them is only weakened by tying it to an essentially unrelated matter. Only the time scale issue is relevant to this mailing list; please take the calendar issue elsewhere. -zefram _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
