Hi
I’ll put that on my calendar right away :)
Yet another potential bug to check for in MJD code ….
Bob
On Jul 13, 2017, at 1:51 PM, Peter Vince petervince1952@gmail.com wrote:
2038 could be an "interesting" year - on the 22nd of April, the MJD hits
65535 (2^16-1) !
On 12 July 2017 at 13:19, Tom Van Baak tvb@leapsecond.com wrote:
Thanks for the notice. Add these to your list:
....
2147483648 0x80000000 Tue Jan 19 03:14:08 2038 GMT (you survived)
While we're at it, we have a rare T&F MJD event coming in 2023:
1968-05-24 00:00:00 UTC (DOY = 145, Fri) = JD 2440000.5 = MJD 40000.0
1995-10-10 00:00:00 UTC (DOY = 283, Tue) = JD 2450000.5 = MJD 50000.0
2023-02-25 00:00:00 UTC (DOY = 56, Sat) = JD 2460000.5 = MJD 60000.0
/tvb
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Good morning all - I hope you enjoyed the Unix 1.5 billion parties? An
ex-colleague who used to work on VAX computers has just sent me this
related message:
OpenVMS also has something to say about time:
.
OpenVMS represents system time as the 64-bit number of 100ns intervals
since midnight preceding November 17, 1858, which is the start of Modified
Julian Day numbering.
.
.
This 100 nanosecond granularity implemented within OpenVMS and the 63-bit
absolute time representation (the sign bit indicates absolute time when
clear and relative time when set) should allow OpenVMS trouble-free time
computations up to 31-JUL-31086 02:48:05.47. At this instant, all clocks
and time-keeping operations in OpenVMS will suddenly fail, since the
counter will overflow and start from zero again.
.
.
You may have to reset your oven timer after this point . . .
Peter
OpenVMS also has something to say about time:
http://h41379.www4.hpe.com/openvms/products/year-2000/leap.html
... one of the most quoted classic bug report replies of all time.
/tvb