It's worth noting that in Ocean's implementation of DV_DATE_TIME, magnitude is indeed a Double.

I agree that 1970-01-01 isn't well suited to this purpose. For example, my own birth date would have a negative magnitude ... yes, some of us were born before Unix

I don't think there is a problem other than the documentation being inconsistent (Peter Gummer's diagnosis is correct in my view). It's arguable that we should not even state an 'origin date' because this is normally only required for systems where the machine representation of dates and date/times is some sort of binary or integer number.

However we are representing dates and times in ISO8601 string form (specific implementations may do something different internally of course). So there's no notion of an 'origin date', except in the possible sense of what the first valid string date is, i.e. 0001-01-01, as PG noted.

The real problem is how to compute 'magnitude' for conversion purposes. Then we need an agreed origin point. I think using '0001-01-01' is sensible since it always guarantees a positive Integer.

HOWEVER... when we get to DV_DATE_TIME.magnitude, it is defined as a Real (i.e. single precision float) representing seconds since the origin point. Now, the number of seconds since 0001-01-01 is about 64E9, and a date/time with fractional seconds could have 12 or more significant digits.

From the wikipedia page on single-precision FP (https://en.wikipedia.org/wiki/Single-precision_floating-point_format):
the maximum representable IEEE 754 floating point value is (2−2−23) × 2127 ≈ 3.402823 × 1038. All integers with six or less significant decimal digits can be converted to a IEEE 754 floating point value without loss of precision, some integers up to nine significant decimal digits can be converted to a IEEE 754 floating point value without loss of precision, but no more than nine significant decimal digits can be stored.

So for DV_DATE_TIME, magnitude probably needs to be a Double.

I don't think using 1970-01-01 as an origin is a good idea in any of these cases, since that is designed for system time-stamps, not calendrical dates and date/times.

How about using 1970/01/01 like many systems. https://en.wikipedia.org/wiki/System_time?

I don't see much point in going back to year 0001. It is also problematic if you take into account timezone such as +10:00, this is is actually 10 hours before 1/1/0001 resulting in a magnitude < 0, which requires a correction and then converting back is incorrect.

I don't have a problem with the magnitude being calculated from this origin, but think there should be some reasonable minimum date which anything less is invalid.