
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


