One of the things I’m learning is that there is are problems with date-time values. The question is whether or not the date part of the date-time should have hyphens. The Frontier implementation does not. The XML-RPC spec says not. But ISO 8601 seems to say they must be present. The built-in JavaScript function includes the hyphens. I don’t have any other implementations that I can easily check against, so I don’t know what offers the most interop with other XML-RPCs. For now I’m documenting the issue, and leaving the JavaScript implementation as it is, for now. This means in this area it does not interop with Frontier, in that Frontier will not understand the JavaScript date-time values. Going in the other direction there is no problem, because I’ve included a workaround.
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[23]
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.