Re: [Rd] chron vs. POSIX

From: Gabor Grothendieck <>
Date: Sat 15 Jul 2006 - 17:01:51 GMT

On 7/14/06, Duncan Murdoch <> 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. mailing list Received on Sun Jul 16 03:05:17 2006

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.1.8, at Sat 15 Jul 2006 - 18:23:58 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.