<div dir="ltr"><div>Thanks Steve. That's a good suggestion regarding the order or fully specifying lubridate names.<br><br>I actually downloaded data.table code and looked through it, and unless I'm missing something, IDateTime is totally separate from everything else. At least if you search for 'IDate' or 'hour' or 'minute', you don't find them mentioned in other .R or .c files besides IDateTime.R<br>

<br></div>And yes - lubridate IS mentioned in IDateTime.R code :)<br><br>###################################################################<br># Date - time extraction functions<br>#   Adapted from Hadley Wickham's routines cited below to ensure<br>

#   integer results.<br>#     <a href="http://gist.github.com/10238">http://gist.github.com/10238</a><br>#   See also Hadley's more advanced and complex lubridate package:<br>#     <a href="http://github.com/hadley/lubridate">http://github.com/hadley/lubridate</a><br>

#   lubridate routines do not return integer values.<br>###################################################################<br><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 6, 2013 at 8:09 PM, Steve Lianoglou <span dir="ltr"><<a href="mailto:mailinglist.honeypot@gmail.com" target="_blank">mailinglist.honeypot@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On Wed, Mar 6, 2013 at 10:47 PM, Victor Kryukov<br>
<<a href="mailto:victor.kryukov@gmail.com">victor.kryukov@gmail.com</a>> wrote:<br>
[snip]<br>
<div class="im">> I'm puzzled about why data table would include this function/classes (isn't<br>
> it better to leave data handling to specialized classes?), but I understand<br>
> that there may be a good reason for that.<br>
<br>
</div>I became a data.table user after IDateTime was in there (and I don't<br>
ever use it, actually), but my *guess* would be that it's there to use<br>
dates as keys for data.table ...<br>
<div class="im"><br>
> Unfortunately, my code is using<br>
> lubridate heavily (it's just too good...), which leaves me in a tough spot -<br>
> I would like to use both. If I had to choose, I would be forced to replace<br>
> all lubridate code with standard R, which is not fun, but I guess I have to<br>
> bite the bullet.<br>
<br>
</div>You don't have to choose one over the other.<br>
<br>
I suspect import order could do the trick. Perhaps import()-ing<br>
data.table first, then lubridate might be all you have to do.<br>
<br>
If not, I *think* if you define hour, mday, mont, etc. in your package code as:<br>
<br>
mday <- lubridate::mday<br>
hour <- lubridate::hour<br>
<br>
And ensure that those functions are loaded first (either by using<br>
Collate: and specifying that file first, or putting that in a function<br>
called aaa.R or something), perhaps your code will recover "just like<br>
that"<br>
<br>
If that doesn't work either, another option is that  you just prefix<br>
every lubridate call in your package code with the lubridate package<br>
name, eg. instead of `year(whenever)` you do<br>
`lubridate::year(whenever)`.<br>
<br>
HTH,<br>
-steve<br>
<div class=""><div class="h5"><br>
--<br>
Steve Lianoglou<br>
Graduate Student: Computational Systems Biology<br>
 | Memorial Sloan-Kettering Cancer Center<br>
 | Weill Medical College of Cornell University<br>
Contact Info: <a href="http://cbio.mskcc.org/~lianos/contact" target="_blank">http://cbio.mskcc.org/~lianos/contact</a><br>
</div></div></blockquote></div><br></div></div></div></div>