5

In this question the issue of using dates in data.tables was discussed. A solution is to use the built-in classes for time and dates. These work with a precision up to the second. Is there a work-around to handle milliseconds in indexed columns?

Community
  • 1
  • 1
Ryogi
  • 5,497
  • 5
  • 26
  • 46
  • 1
    As I read that answer, regular data-time objects (with millisecond accuracy) can exist within data.table objects as long as you do not set them as keys. The IDates class is only needed if you want to key on them. – IRTFM Oct 25 '11 at 22:40
  • @DWin, I need to perform a rolling merge, so I need the data-time object to be indexable. – Ryogi Oct 25 '11 at 23:58
  • 1
    As always, a good question includes a complete specification of the problem and a sample dataset on which to test. – IRTFM Oct 26 '11 at 02:45

2 Answers2

8

The built-in class for Dates and Times, eg POSIXct works to milliseconds (windows) and microseconds (Linux, OS X). You probably haven't turned on the option to have subseconds printed:

R> Sys.time()                            ## under default options
[1] "2011-10-25 17:40:05 CDT"
R> options("digits.secs"=7)              ## you may want this in ~/.Rprofile too
R> Sys.time()
[1] "2011-10-25 17:40:11.177271 CDT"     
R>
Dirk Eddelbuettel
  • 360,940
  • 56
  • 644
  • 725
4

Yeah, data.table requires keys to be integers or similar (i.e. POSIXct rounded to seconds). I would work-around this by storing 1000 * timestamp as your key, and perhaps having a separate column which is the non-rounded POSIXct. Or you can convert to POSIXct on the fly whenever you need it.

Muhammad Waliji
  • 56
  • 2
  • 2
    Yes e.g. `as.integer(1000*as.numeric(format(Sys.time(),"%H%M%OS3")))` `[1] 15017710`, as a work around. Having the date and time in two columns can be good when it comes to rolling joins: if you want the prevailing record within the same day but not from a previous day. – Matt Dowle Oct 26 '11 at 01:02