On 7/15/2006 1:01 PM, Gabor Grothendieck wrote: > On 7/14/06, Duncan Murdoch <[EMAIL PROTECTED]> 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.
I think that would be preferable to making it a base package, but it's not the only way to publicize it. Why not add something to the Wiki to compare the various possibilities for storing dates and times? Duncan Murdoch > >> 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. > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel