Using a date/time class suitable for numeric computation and also as key for merging

Question

I am working with some diurnal time series where times have to be represented down to minutes.

In various tools, some date/time classes are represented as integers since epoch (e.g., R's POSIX classes, Python/Numpy); other ones are fractional days since epoch (e.g., R's chron package, also Matlab).

It seems that integer representations allows you to perform numerical calculations (sum, difference) but ALSO provide a way to merge/match by them, whereas it is more difficult to merge/match by time for those represented by fractional days (floating point numbers).

This is more of a conceptual question, but is there a good reason for using fractional days or floats for time representations? For R, it is strange that even POSIX classes are numeric rather than integer.

> (p <- as.POSIXct("2011-01-01"))
[1] "2011-01-01 CST"
> (unclass(p <- as.POSIXct("2011-01-01")))
[1] 1293861600
attr(,"tzone")
[1] ""
> class(unclass(p <- as.POSIXct("2011-01-01")))
[1] "numeric"

Was this because of R's early integer storage limitation? Or is there some other advantage to using floating-point representations? To merge I convert my date/time objects into formatted character strings but is this the canonical way (I most often use the chron package in R)?

Answer 1

POSIXct is numeric because it offers 53 bits of precision, as opposed to the 32 bits of 4-byte integers. R was developed mostly on 32-bit platforms in the latter half of the last century, and using integers would have made it susceptible to the year-2038 problem. Now that 64-bit ints are available that would have been be a better choice, but we're stuck with 53 bits for now. In the year ca. 285420000 when this will be a problem, we can revisit it.