chron vs. POSIX
On 7/14/06, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
On 7/14/2006 3:38 PM, Sebastian Luque wrote:
Hi, One of the big decisions when writing code is how to handle dates and times. Gabor Grothendieck provided an excellent overview of the issue in his R News 4/1 (2004) article, and many users and developers are probably using it as a guide. The proposed guideline is to use the simplest class required; as Gabor put it "use Date if possible, otherwise use chron, and otherwise use POSIX". This seems to me a very efficient strategy, judging from my own experiences and those of others users. All but the simplest calculations with POSIX objects demand great care, due to time zone and and daylight savings considerations. Therefore, I've always chosen chron for relatively complex projects, where I don't need to deal with time zones or daylight savings problems. The ease with which objects can be switched from numeric to chron representations is a major advantage IMHO?. If Gabor's recommendations are to be followed, wouldn't it make sense to include chron in base R? Given that flexibility for handling time variables is so fundamental, the addition of chron to base R would provide users everything they need to work with time, without the need to rely on an external package. What do others think?
Putting something into base R essentially means that it is to be taken over by R core. I think chron is being adequately maintained now (the R maintainer is already a member of R core), so I don't see a need for that. I don't see a problem having a package on CRAN. If it's a good package and people realize that it's good, and it remains available for others to use, then what problem is being solved?
I think the problem is that there is nothing to signal its importance. Perhaps chron should be added to the "recommended" package list.
as.vector(installed.packages(priority = "base")[,1])
[1] "base" "datasets" "graphics" "grDevices" "grid" "methods" [7] "splines" "stats" "stats4" "tcltk" "tools" "utils"
as.vector(installed.packages(priority = "recommended")[,1])
[1] "boot" "class" "cluster" "foreign" "KernSmooth" [6] "lattice" "MASS" "mgcv" "nlme" "nnet" [11] "rpart" "spatial" "survival" Alternately, a new naive datetime class, i.e. a datetime class not utlitizing time zones and daylight savings time, could be created based on experience with "chron" and the existing classes such that its internal representation is like that of chron but its accessor methods are similar to existing core methods to enhance uniformity of use among the various date and time classes.