11
votes

Why does Delphi use double (8 bytes) to store date and time instead of Int64 (8 byte as well)? As a double precision floating point is not an exact value, I'm curious wether the precision of a unix date and time stored in an Int64 value will be better than the precision of a Delphi date and time?

1
If I recall, precision is related to operations only, which is why DateUtils provides the tools to perform such operations. FWIW, the whole numbers reflect the date, and the decimals reflect the time of day. But as far as why, you'd have to ask the original developer, which I doubt they'd come here to answer.Jerry Dodge
@JerryDodge Precision is actually quite relevant because the precision of TDateTime varies significantly depending on the absolute value. There is fine granularity close to the epoch, but it gets progressively coarser as you move away from the epoch. That's a direct consequence of the use of a floating point type.David Heffernan
@David Indeed, I didn't mean they're not relevant - just pointing that out.Jerry Dodge
@JerryDodge Precision is not related to the operations only. Different representations of date/time are capable of very different precisions. In the case of TDateTime the precision depends on how far you are from the epoch.David Heffernan
@David: how far from the epoch would you need? A value in the year 9999 would require approx. 22 bits for the date, which would leave 31 bits for hours, minutes, seconds and milliseconds, which is much better than the precision of a Single. That is precise enough, IMO. The current date is 118 years away from the epoch, which would only require a few bits less.Rudy Velthuis

1 Answers

23
votes

The simple explanation is that the Delphi TDateTime type maps directly to the OLE/COM date/time format.

Embarcadero chose to use an existing date/time representation rather than create yet another one, and selected, what was at the time, the most obvious platform native option.

A couple of useful articles on Windows date/time representations:

As far as precision goes, you would like to compare Unix time to TDateTime. Unix time has second precision for both 32 or 64 bit values. For values close to the epoch, a double has far greater precision. There are 86,400 seconds in a day, and there are many orders of magnitude more double values between 0 and 1, for instance. You need to go to around year 188,143,673 before the precision of Unix time surpasses that of TDateTime.

Although you have focused on the size of the types, the representation is of course crucially important. For instance, if instead of representing date as seconds after epoch, it was represented as milliseconds after epoch, then the precision of Unix time would be 1000 times greater. Of course the range would be reduced by 1000 times also.

You need to be wary of considering precision of these types in isolation. These types don't exist in isolation, and the source of the values is important. If the time is coming from a file system say, then that will in fact determine the precision of the value.