time-nuts@lists.febo.com

Discussion of precise time and frequency measurement

View all threads

MJD 60000 this week

TV
Tom Van Baak
Mon, Feb 20, 2023 12:11 AM

Here's a nerdy timing post...

It's now Monday in UTC-land; the current time is:

2023-02-20 00:00:00 UTC (DOY = 51, Mon, STOD = 0) = JD 2459995.50000 =
MJD 59995.000000
Sun Feb 19 16:00:00 2023 (UTC-8 Pacific Standard Time)

This means in 5 days it will be MJD 60000. There likely won't be any
trouble but even I have some scripts that do "sanity checks" on MJD
expecting the first digit to be 5 or maybe 4. They will be fixed before
they fail at the end of the week.

Humans prefer calendars (year, month, day) and clock faces (hours,
minutes, seconds) in spite of the awkward variable length of months and
years or Babylonian base 24 or 60 arithmetic for time of day. In
contrast, most h/w and s/w prefers to work with some form of integer
linear time because it makes the math so much easier.

Keeping track of linear time with JD (Julian Date) is very common in
astronomy. Keeping track of linear time with MJD (Modified Julian Date)
is very common in time & frequency metrology, including satellites such
as GPS. [1] You've probably read papers about time scales, atomic
clocks, UTC(k), GPS performance, and stuff like that. The x-axis is very
commonly MJD.

All linear time scales have an origin date (aka epoch). Here are some
examples:

//   01-Jan-1601 (JD 2305813.5) is WNT (Windows NT) epoch
//   17-Nov-1858 (JD 2400000.5) is VMS epoch  (MJD 0)
//   01-Jan-1958 (JD 2436204.5) is TAI epoch  (MJD 36204)
//   01-Jan-1900 (JD 2415020.5) is NTP epoch  (MJD 15020)
//   01-Jan-1970 (JD 2440587.5) is UNIX epoch (MJD 40587)
//   06-Jan-1980 (JD 2444244.5) is GPS epoch  (MJD 44244)
//   01-Jan-2000 (JD 2451544.5) is Y2K epoch  (MJD 51544)

The leading decimal digit of MJD changes only once every ~27 years. MJD
40000 happened during 1968, MJD 50000 happened during 1995, and we all
get to experience MJD 60000 happening right now in 2023. It's not a
dangerous "rollover" or "overflow" event, but simply a rare chance to
see a change in leading digit. Like a decade birthday; something to
celebrate.

Many of us are used to seeing a 5 digit number starting with 5 and know
it's a date. You'll now get used to seeing MJD numbers in the 60k range.
Note that the entire history of time-nuts, and even the Tom Clark
mailing lists before it, occurred during the 50k era of MJD.

Again, I don't expect any serious problems, but keep your eyes open for
anything strange 5 days from now at:

2023-02-25 00:00:00 UTC (DOY = 56, Sat, STOD = 0) = JD 2460000.50000 =
MJD 60000.000000
Fri Feb 24 16:00:00 2023 (UTC-8 Pacific Standard Time)

p.s. Special prize to anyone who posts a photo of the MJD 60k event at
home. The last time we had this much fun with MJD was [2]:

http://leapsecond.com/pages/mjd52325/

/tvb

[1] https://en.wikipedia.org/wiki/Julian_day

Note the historical origin of MJD and its relationship to both Sputnik
and 36-bit mainframe computers.

[2] https://www.febo.com/pipermail/time-nuts/2006-April/020455.html

Here's a nerdy timing post... It's now Monday in UTC-land; the current time is: 2023-02-20 00:00:00 UTC (DOY = 51, Mon, STOD = 0) = JD 2459995.50000 = MJD 59995.000000 Sun Feb 19 16:00:00 2023 (UTC-8 Pacific Standard Time) This means in 5 days it will be MJD 60000. There likely won't be any trouble but even I have some scripts that do "sanity checks" on MJD expecting the first digit to be 5 or maybe 4. They will be fixed before they fail at the end of the week. Humans prefer calendars (year, month, day) and clock faces (hours, minutes, seconds) in spite of the awkward variable length of months and years or Babylonian base 24 or 60 arithmetic for time of day. In contrast, most h/w and s/w prefers to work with some form of integer linear time because it makes the math so much easier. Keeping track of linear time with JD (Julian Date) is very common in astronomy. Keeping track of linear time with MJD (Modified Julian Date) is very common in time & frequency metrology, including satellites such as GPS. [1] You've probably read papers about time scales, atomic clocks, UTC(k), GPS performance, and stuff like that. The x-axis is very commonly MJD. All linear time scales have an origin date (aka epoch). Here are some examples: //   01-Jan-1601 (JD 2305813.5) is WNT (Windows NT) epoch //   17-Nov-1858 (JD 2400000.5) is VMS epoch  (MJD 0) //   01-Jan-1958 (JD 2436204.5) is TAI epoch  (MJD 36204) //   01-Jan-1900 (JD 2415020.5) is NTP epoch  (MJD 15020) //   01-Jan-1970 (JD 2440587.5) is UNIX epoch (MJD 40587) //   06-Jan-1980 (JD 2444244.5) is GPS epoch  (MJD 44244) //   01-Jan-2000 (JD 2451544.5) is Y2K epoch  (MJD 51544) The leading decimal digit of MJD changes only once every ~27 years. MJD 40000 happened during 1968, MJD 50000 happened during 1995, and we all get to experience MJD 60000 happening right now in 2023. It's not a dangerous "rollover" or "overflow" event, but simply a rare chance to see a change in leading digit. Like a decade birthday; something to celebrate. Many of us are used to seeing a 5 digit number starting with 5 and know it's a date. You'll now get used to seeing MJD numbers in the 60k range. Note that the entire history of time-nuts, and even the Tom Clark mailing lists before it, occurred during the 50k era of MJD. Again, I don't expect any serious problems, but keep your eyes open for anything strange 5 days from now at: 2023-02-25 00:00:00 UTC (DOY = 56, Sat, STOD = 0) = JD 2460000.50000 = MJD 60000.000000 Fri Feb 24 16:00:00 2023 (UTC-8 Pacific Standard Time) p.s. Special prize to anyone who posts a photo of the MJD 60k event at home. The last time we had this much fun with MJD was [2]: http://leapsecond.com/pages/mjd52325/ /tvb [1] https://en.wikipedia.org/wiki/Julian_day Note the historical origin of MJD and its relationship to both Sputnik and 36-bit mainframe computers. [2] https://www.febo.com/pipermail/time-nuts/2006-April/020455.html
SA
Steve Allen
Mon, Feb 20, 2023 3:21 AM

On Sun 2023-02-19T16:11:03-0800 Tom Van Baak via time-nuts hath writ:

All linear time scales have an origin date (aka epoch).
Here are some examples:

01-Jan-1958 (JD 2436204.5) is TAI epoch  (MJD 36204)

There are so many "yes but"s in that.

The epoch of TAI is 1961-01-01T20:00:00 UT2(OP).
The scale A3 which became TAI was not named until then.

https://www.ucolick.org/~sla/leapsecs/taiepoch.html

Early atomic time had many hiccups.

https://www.ucolick.org/~sla/leapsecs/earlyAT.html

TAI did not exist until 1971, and even ignoring all the early hiccups
TAI is not linear because

The rate of TAI was stepped on 1977-01-01.
TAI suffered from a notable seasonal rate variation into the early 1980s.

--
Steve Allen                    sla@ucolick.org              WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street              Voice: +1 831 459 3046        Lng -122.06015
Santa Cruz, CA 95064          https://www.ucolick.org/~sla/  Hgt +250 m

On Sun 2023-02-19T16:11:03-0800 Tom Van Baak via time-nuts hath writ: > All linear time scales have an origin date (aka epoch). > Here are some examples: > 01-Jan-1958 (JD 2436204.5) is TAI epoch  (MJD 36204) There are so many "yes but"s in that. The epoch of TAI is 1961-01-01T20:00:00 UT2(OP). The scale A3 which became TAI was not named until then. https://www.ucolick.org/~sla/leapsecs/taiepoch.html Early atomic time had many hiccups. https://www.ucolick.org/~sla/leapsecs/earlyAT.html TAI did not exist until 1971, and even ignoring all the early hiccups TAI is not linear because The rate of TAI was stepped on 1977-01-01. TAI suffered from a notable seasonal rate variation into the early 1980s. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m
MD
Magnus Danielson
Mon, Feb 20, 2023 12:26 PM

Hi,

On 2023-02-20 04:21, Steve Allen via time-nuts wrote:

On Sun 2023-02-19T16:11:03-0800 Tom Van Baak via time-nuts hath writ:

All linear time scales have an origin date (aka epoch).
Here are some examples:
01-Jan-1958 (JD 2436204.5) is TAI epoch  (MJD 36204)

There are so many "yes but"s in that.

The epoch of TAI is 1961-01-01T20:00:00 UT2(OP).
The scale A3 which became TAI was not named until then.

https://www.ucolick.org/~sla/leapsecs/taiepoch.html

Early atomic time had many hiccups.

https://www.ucolick.org/~sla/leapsecs/earlyAT.html

TAI did not exist until 1971, and even ignoring all the early hiccups
TAI is not linear because

The rate of TAI was stepped on 1977-01-01.
TAI suffered from a notable seasonal rate variation into the early 1980s.

Also, there is no "counter start at zero" type of epoch for TAI, a
common misunderstanding by especially programmers that seems to think
"epoch" has that meaning, always.

There is TAI-like time-scales, such as GPS and PTP, where counters was
set to zero.

PTP starts a bit into 1969 for it to be ticking in SI seconds such that
it has integer offset as UTC starts with leap seconds, essentially a
variant of the UNIX epoch/time but which align to integer relationship
after 1 Jan 1972, so that the leap second count adds to make UTC. UTC
did not have SI seconds prior to 1 Jan 1972, so the UNIX/POSIX type of
clock starting from 1 Jan 1970 and count SI-seconds ends up not being
UTC-aligned.

Cheers,
Magnus

Hi, On 2023-02-20 04:21, Steve Allen via time-nuts wrote: > On Sun 2023-02-19T16:11:03-0800 Tom Van Baak via time-nuts hath writ: >> All linear time scales have an origin date (aka epoch). >> Here are some examples: >> 01-Jan-1958 (JD 2436204.5) is TAI epoch  (MJD 36204) > There are so many "yes but"s in that. > > The epoch of TAI is 1961-01-01T20:00:00 UT2(OP). > The scale A3 which became TAI was not named until then. > > https://www.ucolick.org/~sla/leapsecs/taiepoch.html > > Early atomic time had many hiccups. > > https://www.ucolick.org/~sla/leapsecs/earlyAT.html > > TAI did not exist until 1971, and even ignoring all the early hiccups > TAI is not linear because > > The rate of TAI was stepped on 1977-01-01. > TAI suffered from a notable seasonal rate variation into the early 1980s. Also, there is no "counter start at zero" type of epoch for TAI, a common misunderstanding by especially programmers that seems to think "epoch" has that meaning, always. There is TAI-like time-scales, such as GPS and PTP, where counters was set to zero. PTP starts a bit into 1969 for it to be ticking in SI seconds such that it has integer offset as UTC starts with leap seconds, essentially a variant of the UNIX epoch/time but which align to integer relationship after 1 Jan 1972, so that the leap second count adds to make UTC. UTC did not have SI seconds prior to 1 Jan 1972, so the UNIX/POSIX type of clock starting from 1 Jan 1970 and count SI-seconds ends up not being UTC-aligned. Cheers, Magnus