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? +---- *Footnotes* ----+ ? This is possible with POSIX classes too by using the structure() function, but a post by Brian Ripley to the effect that it may not be practical in the long term further convinced me of this. -- Sebastian P. Luque Department of Biology Memorial University of Newfoundland sluque at mun.ca
On 14 July 2006 at 14:38, Sebastian Luque wrote: | 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 Future historians will provide a fuller account of the extended debates, but my reading of these discussions here over the last few years leaves me with the impression that Gabor is arguing for chron in a manner that is simultaneously informed, polite, persistent and yet ... utterly isolated. Date and POSIXt have served me well over the last few years. They are maintained and being extended [ 1 ]. Chron, to the best of my knowledge, is dead code so I'd bet against it appearing in core R any time soon. Regards, Dirk [ 1 ] I had some pleasant exchanges with Brian Ripley where I was able to suggest a few extension relative to the new millisecond granularity in POSIXt and its interfaces. -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison
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? Duncan Murdoch