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 <maechler@stat.math.ethz.ch> wrote:>>>>> "BDR" == Prof Brian Ripley <ripley@stats.ox.ac.uk> >>>>> 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 <maechler@stat.math.ethz.ch> 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 <>< ______________________________________________ R-help@stat.math.ethz.ch mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-help
On Wed, 2003-09-17 at 19:03, 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....> 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:When I don't want to be bothered with time zones, DST, etc, I set all time zones to UTC. Works fine for me. I'd love to say I thought of it myself, but it's an old trick frequently used in industrial real-time control systems that have daylight savings features when they're not welcome. Cheers Jason -- Indigo Industrial Controls Ltd. http://www.indigoindustrial.co.nz +64-(0)21-343-545
The problem with using a convention is that you can't be guaranteed that all the routines you use also use that same convention. You still have to understand how each of the routines you use handle time zones and you are dragged into thinking about an irrelevant piece of information violating modularity and making your code more error prone. (I think I made some of these points already but I thought they bear repeating in light of this discussion.) Essentially the POSIXt0 classes discussed in the link in my previous posting do what you are suggesting internally but use the class mechanism to enforce it. Chron also has no timezone so does not have the problems of POSIXt in this regard. --- Jason Turner <jasont@indigoindustrial.co.nz> wrote: On Wed, 2003-09-17 at 19:03, 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....> 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:When I don't want to be bothered with time zones, DST, etc, I set all time zones to UTC. Works fine for me. I'd love to say I thought of it myself, but it's an old trick frequently used in industrial real-time control systems that have daylight savings features when they're not welcome. Cheers Jason -- Indigo Industrial Controls Ltd. http://www.indigoindustrial.co.nz +64-(0)21-343-545
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 <maechler at stat.math.ethz.ch> wrote:
> >>>>> "BDR" == Prof Brian Ripley <ripley at
stats.ox.ac.uk>
> >>>>> 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 <maechler at stat.math.ethz.ch>
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 <><
>
> ______________________________________________
> R-help at stat.math.ethz.ch mailing list
> https://www.stat.math.ethz.ch/mailman/listinfo/r-help
>
> ______________________________________________
> R-help at stat.math.ethz.ch mailing list
> https://www.stat.math.ethz.ch/mailman/listinfo/r-help
>
>