Unreal. Fourteen years ago a standard was published (ISO 8601:2004) which clearly defined how things should be. Problem is that software developers do not spend their lives re-implementing “standard” software for the rest of their lives.
ISO gave us (back in 2004) this format 20180609T221145Z
What the world wants now is this format 2018-06-09T22:11:45+00:00 (we avoid timezone abbreviations and geo-political nonsense)
I retired from the big data world in 2004, so I never would have had cause to change my preferred world – 20180609T221145Z. To tell the truth, since just before 2000-01-01 I actually preferred the “Astronomical (Julian) day number (at noon UTC): 2458279.5” which for my machines this morning worked out to 2458279.03405093.
From the wikipedia we see
November 17, 1858, 00:00:00 UT is the zero of the Modified Julian Day (MJD) equivalent to Julian day 2400000.5
and we all basically know that the VMS clock started there 😉 In earlier times (snicker) I discovered the “bad things” that would happen if one entered a proper geocentric clock offset in a TOPS-10 system — I mean, c’mon, I had it right within 200 yards. All hell broke loose in all time-based things. Wonder why it required an OS rebuild to set/change that value.
As a reminder to anyone who uses a database that I have built — 20180609 — is not a date, nor is 2018060915270001 — but it is a very fast integer index 😉 I can’t insert things in my databases faster than 10,000 per second. I learned the hard way that telescope telemetry databases surely can 😉
Ahhh, dates. I would rather slip the bass DI track by 87 samples so it lines up with the bass amp track these days.