[Rd] Enhancement suggestion: POSIXt0

Gabor Grothendieck ggrothendieck at volcanomail.com
Wed Aug 13 12:29:13 MEST 2003


This is a proposal for a simple partial solution to the date
problems in R.  It defines new classes, POSIXct0 and POSIXlt0,
which are similar to their non trailing zero counterparts
but have no timezone or daylight time.  Internally they look
like GMT times but they have their own methods.

PROBLEM 
Problems with POSIX dates appear when you want to
work with daily data or time data and just want naive time
but instead you are forced into unwanted considerations
regarding standard vs. daylight time and time zones.

chron is one solution but does not appear to be consistently
supported across R and it is not in the base.  Using GMT
timezone is another except that you can't be sure that a
routine to which you pass that date is also assuming GMT
when representing times.

With existing POSIXt times you either do not know what time
zone a routine you pass the time to is going to assume or
else you have to laboriously keep track of and pass around
timezones.  If your application only depends on naive time
then you are still forced into timezone and standard vs.
daylight considerations which contradicts the idea of
increasing modularity and decreasing complexity (i.e. a
module should not depend on irrelevant modules).  

ADVANTAGES 
The proposal has the advantage of being highly
consistent with the current system, easy to learn and use
since it obeys the same rules as existing POSIX dates and
its easy to implement since it leverages off existing
facilities.  Also its not prone to or at least less prone to
date and time bugs so its more likely to work across a wide
range of systems than POSIXt.  For example, see:
https://www.stat.math.ethz.ch/pipermail/r-devel/2003-August/027165.html
https://www.stat.math.ethz.ch/pipermail/r-devel/2003-August/027166.html

With POSIXt times there is no timezone or standard vs.
daylight time so you avoid troubles with such considerations.  
You avoid having to pass around timezone info since there is none.
Datetime arithmetic is more regular, e.g.  the same time on the 
following day is found by adding 24*60*60 irrespective of standard 
vs. daylight times.

SOLUTION 
Define new classes POSIXt0, POSIXct0 and POSIXlt0
which are the same as their non trailing 0 counterparts
except that they have no concept of timezone or daylight vs.
standard time.  

Internally the new classes would represent datetimes the
same way POSIXct and POSIXlt currently represent GMT times.
The new classes would have their own methods.

What is particularly important is that in order to avoid
subtle errors that they NOT be automatically converted to
and from existing POSIX classes.  (Automatic conversion
between POSIXct0 and POSIXlt0 is permissable.) For example,
if d is a vector of POSIXct0 dates then plot(d,y) will use
the plot.POSIXct0 method, if it exists, or be an error if it
does not exist.  (S3 classes are assumed since 
S4 classes are not used in the base.)

Explicit conversions to the respective classes would be
handled by as.POSIXct, as.POSIXlt, as.POSIXct0 and
as.POSIXlt0.  plot, format, etc. would have their own
POSIXct0 and POSIXlt0 methods.  datetime arithmetic would be
supported in the same way as with existinig POSIX classes
with the proviso that you cannot mix the 0 and non-0
classes.  

BASE 
It would be possible to define a POSIXt0 package;
however, they are mainly useful if used consistently across
R so being in the base would be best.  Given that the hard
work has already been done they would not bloat the base
significantly.

OTHER 
It would also be possible (though not necessary for
the above) to define a date class that held the date but not
time.  It could use the same representation as POSIXt0 and
just ignore the time (or zap it in calculations where it
might interfere). This is relatively straightforward with
POSIXt0 but with POSIXt is more problematic since the date
corresponding to a given datetime is unique for POSIXct0 but
is timezone dependent for POSIXct.

CHRON 
Moving chron to the base is another solution that
could be considered as an alternative to this one.



More information about the R-devel mailing list