This question already has an accepted answer, but I would like to add my observations on this topic.
datetime:
- Internally holds the value as a complex double. The real part is the number of milliseconds since Modern UTC Epoch = 1970-Jan-01 UTC. The imaginary part is a "correction" to add to maintain precision.
duration:
- Internally holds the value as a real double representing milliseconds.
You can already see the disconnect. The datetime class is designed to hold values to a higher precision than the duration class. Creating datetime variables with the higher precision is fine, but as soon as you subtract them a duration results and you lose that precision. This is an unfortunate situation and could have been avoided if the duration class held the value the same way that datetime variables do. I have made the suggestion to TMW to change this and make the duration class consistent with the datetime class, but I don't know if they will ever do it.
Example of the problem:
dt = datetime(2000,1,1,1,1,1.2345678912345)
dt =
01-Jan-2000 01:01:01
You can see that the full precision of the original seconds is there. You can even look at the internals:
sdt = struct(dt)
Warning: Calling STRUCT on an object prevents the object from hiding its implementation details and should thus be avoided. Use DISP or DISPLAY to see the visible public details of an object. See 'help struct' for more information.
sdt =
UTCZoneID: 'UTC'
UTCLeapSecsZoneID: "UTCLeapSeconds"
ISO8601Format: 'uuuu-MM-dd'T'HH:mm:ss.SSS'Z''
ISO8601FormatPattern: regexpPattern("uuuu-MM-dd'T'HH:mm:ss(\.S{1,9})?'Z'")
epochDN: 719529
MonthsOfYear: [1x1 struct]
DaysOfWeek: [1x1 struct]
data: 946688461234.568 + 2.01407499389461e-05i
fmt: ''
tz: ''
dfltPivot: 1974
dateFields: [1x1 struct]
noConstructorParamsSupplied: [1x1 struct]
What is the data value? Well, here is a demonstration:
mutc = dt - datetime(1970,1,1)
You can see that the data value in the dt variable is in fact milliseconds since Modern UTC epoch. To see the purpose of the imaginary part, note that the duration calculated from a datetime difference does not retain the seconds accuracy:
The trailing digits of the duration seconds does not match the original. Not good.
But the datetime variable, with the correction, is able to get the original seconds accurately. E.g.,
(mod(real(sdt.data),60000) + imag(sdt.data)) / 1000
When calculating the second value, internally the equivalent of the above is done to maintain precision. This is all good as far as it goes, but as soon as you subtract two datetime variables you lose this! Sigh ...
My advice when you need to retain precision is to AVOID THE DURATION CLASS and to AVOID SUBTRACTING DATETIME VARIABLES. You may have to write your own code to subtract datetime variables piecemeal and maintain the difference in your own format. If you have a string of "extended precision" you need to add to a datetime, separate the string into pieces that can individually be held accurately in doubles, and add them to the datetime sequentially to maintain precision. E.g., see this related thread:
