[Rd] chron vs. POSIX

[Gabor Grothendieck]

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.