I agree with this. I am also in a situation where I need only dates (no
need for timezones or daylight saving time), and times actually get in a
way, complicating code and creating a mess. I've had occasions when
seq.POSIXt() did not work for me (could not generate a simple daily
sequence) due to the time component, which I don't need and never
specified. Even just the display of time component ("2002-10-20 08:00:00
EDT" vs. "2002-10-20") makes dates bulky and hard to track.I also converted one of my date related function to chron and see much improvement in code readability and reliability. On the one hand, I'd like to stay with R base and not introduce another library dependency, however chron provides the level of clarity beyond POSIXt classes (this goes for function naming as well: chron(), dates(), times() are easier to remember then strftime(), strptime() ...) Don't have a remedy to offer, I'll leave this to more experienced users. Just my 2c . Best regards, Aleksey On Wed, 17 Sep 2003, Gabor Grothendieck wrote: > > The problem with POSIXt is that you must consider timezones > and daylight vs. standard time issues even if you don't want > to. This violates modularity (viz. your routines becomes coupled > to unrelated information) and leads to subtle errors where different > routines are assuming different time zones. > > The problem is that the time, date, day of the week, month, etc. > of a date depend on its time zone so even if you are just concerned > with daily data in a fixed time zone, say, you are still dragged > into time zone and standard vs. daylight considerations. > > I recently converted a program using POSIXt to chron and it allowed > me to eliminate all the tz parameters that I was passing around and > even better it meant I did not even have to THINK about time zones > and all the associated headaches they were giving me. > > I had previously suggested that we either put chron into the base > or create a new timezone-less version of POSIXt to complement what > is already in the base. See: > > https://stat.ethz.ch/pipermail/r-devel/2003-August/027269.html > > > > > --- Martin Maechler <[EMAIL PROTECTED]> wrote: > >>>>> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]> > >>>>> on Wed, 17 Sep 2003 06:58:48 +0100 (BST) writes: > > BDR> On Tue, 16 Sep 2003, Deepayan Sarkar wrote: > >> Is the date class standard enough to warrant including a > >> check for it in lattice ? > > BDR> I don't think so. The POSIX*t classes in R are the > BDR> most standard, followed by the chron package and only > BDR> then the date package. > > Definitely. And I think we should encourage people to > upgrade to POSIX.t from "chron" (let alone "date") more > strongly {Note that there have been as.POSIXct() methods for > these classes since the beginning of the POSIX.t classes. > > Could "chron" and "date" users be heard about what > functionality they are missing in POSIX.t ? > > On the other hand, the recommended package "survival" has > a(nother?) class "date" and that package is based on S(plus) code > and may hence not be convertible sensibly ? > > Martin Maechler <[EMAIL PROTECTED]> http://stat.ethz.ch/~maechler/ > Seminar fuer Statistik, ETH-Zentrum LEO C16 Leonhardstr. 27 > ETH (Federal Inst. Technology) 8092 Zurich SWITZERLAND > phone: x-41-1-632-3408 fax: ...-1228 <>< > > ______________________________________________ > [EMAIL PROTECTED] mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-help > > ______________________________________________ > [EMAIL PROTECTED] mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-help > > ______________________________________________ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-help
