Data.table: Conflicting date time accessors with `lubridate`

[vspinu]

A pretty long list of date-time accessors in data.table conflicts with lubridate:

     hour(x)   
     yday(x)   
     wday(x)   
     mday(x)   
     week(x)   
     month(x)  
     quarter(x)
     year(x)   

A lot of people, including myself, use both data.table and lubridate routinely. So this overlap is rather an inconvenience. There was even a recent bug report to lubridate as a result of the name collision.

Given that data.table is not dedicated package for working with date-times I wonder if date-time functionality could be split into a separate package or date-time accessors deprecated.

The definitions of these functions in data.table are very basic. In lubridate these are all generics with methods for a variety of classes. Setters are also provided. The default method is the same as it is defined in data.table.

[arunsrinivasan]

Loading data.table and then lubridate or using :: operator should resolve this? Deprecating it for name clashes seems extreme.

[vspinu]

Deprecating it for name clashes seems extreme.

The main proposal was to move IDate into a specialized package. It would make data.table a cleaner package.

[zippeurfou]

+1

[jangorecki]

@vspinu @zippeurfou
Namespace collision can always happen, what if the next version of other popular package creates a function with overlapping name?

• The best way to handle that for production code is to use importFrom in NAMESPACE file in your package.
• The most convenient way to handle that for interactive use is to load packages in required order, eventually use :: operator.

You may be also interested in How does R handle overlapping object names?.

[aryoda]

Note:

Some unit tests of data.table fail if you do load lubridate after data.table.

IMHO You shouldn't load lubridate if you want to run the
unit tests to verify the correct installation of data.table!

library(lubridate)
library(data.table)
test.data.table()  # runs without errors

If you reset the R session and load data.table first you will get some unit test errors

library(data.table)
library(lubridate)
test.data.table()  # runs with unit test errors

saying e. g.

Running test id 546 Test 546 ran without errors but failed check that x equals y:

[mattdowle]

Thanks @aryoda. More to do then, including adding tests to test.data.table(with.other.packages=TRUE).

[jangorecki]

It make sense to attach all exported data.table functions at the beginning of test.data.table(), or eventually detect if exported data.table got masked.