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 <[EMAIL PROTECTED]> 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 ______________________________________________ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-help
