Tom Van Baak wrote: >But since some of you are real picky about formal definitions, >my question is what to do about MJD -- is it UT1-based or it is >UTC-based?
Both. Also TAI, TT, TCG, and TCB. And UT0, UT2, UT1R, UT2R, UTC-SLS, and other flavours of UT. The use of JD or MJD doesn't imply which time scale is being used; rather, it is a way of specifying a date and time-of-day that can be applied to any of these time scales. A JD value has nearly the same status here as a date specified in the Gregorian calendar: such calendar dates are also used with all of these time scales. The only real difference in status is that the Gregorian calendar and sexegesimal time-of-day also get applied to timezone-relative timing, whereas JD and MJD preclude the use of timezones. We have the Chronological Julian Date (CJD) for timezones. >And if UTC-based, what's the right thing to do when the day has a +/- >leap second? Mostly the right thing is to avoid using JD/MJD, because it gets confusing. The expressions that do use JD/MJD with UTC, such as the defining expressions for rubber UTC in tai-utc.dat, work on the basis that MJD is always the expected integer (and JD the expected half-integer) at 00:00:00 UTC, and that within a UTC day JD/MJD increases by 1/86400 per UTC second. This means there's a discontinuity in JD/MJD at the end of a positive leap, with JD/MJD values during the leap being ambiguous with the first second of the following day. One must understand from context which second one is dealing with. It is sometimes useful to split an MJD value into integral and fractional parts. The integral part is the Modified Julian Day Number (MJDN), and I call the fractional part the Modified Julian Day Fraction (MJDF). By definition, MJD = MJDN + MJDF. When applied to a leapless time scale, MJDN = floor(MJD), and MJDF is always in the range [0, 1). But when applied to UTC, MJDN is best taken to be the number corresponding to the UTC day (even if it started more than 86400 seconds ago), and MJDF gives the time within that day (even if that's more than 86400 seconds). The (MJDN, MJDF) tuple is unambiguous: during a leap second MJDF >= 1. Even if one doesn't actually need the unambiguous decoding, explicitly separating these two quantities can make expressions using MJD with UTC clearer. If one wants to display a UTC-based MJD value, it's tempting to adopt a digit with value ten, and use that in the first fractional place to distinguish a leap second from the following second. For example, MJD 57753.99999 came during the second preceding the recent leap second, MJD 57753.A0001 came during the leap second, and MJD 57754.00001 came during the following second. I've never implemented this, but I find it a useful way to think. -zefram _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
