[Rd] chron vs. POSIX

[Duncan Murdoch]

On 7/15/2006 1:01 PM, Gabor Grothendieck wrote:
> 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.

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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel