[Rd] new chron problems in RW0990

Kurt Hornik Kurt.Hornik@ci.tuwien.ac.at
Sun, 13 Feb 2000 16:48:14 +0100

>>>>> Prof Brian Ripley writes:

>> From: "Jens Oehlschlägel-Akiyoshi" <jens.oehlschlaegel-akiyoshi@mdfactory.de>
>> Date: Fri, 11 Feb 2000 16:56:36 +0100
>> In RW0901 I could
>> > dates("01/01/2000")
>> [1] 01/01/100
>> where only the printing was wrong, but the double numeric representation of
>> the chron object was calculated correctly
>> but now in RW0990

> The difference is not in rw0901/rw0990 but in the version of chron in
> use.  There is an rw0901 version of chron 2.2-2 too.

>> > dates("01/01/2000")
>> Error in fun(yy, ...) : must be 2-digit (numeric) year specification
>> and also the followig doesn't help
>> > dates("01/01/2000", format="dd/mm/yyyy")
>> Error in names<-.default(*tmp*, value = fnames) :
>> names attribute must be the same length as the vector
>> In addition: Warning message:
>> wrong number of fields in entry(ies) 1 in: unpaste(dates., sep = fmt$sep,
>> fnames = fmt$periods, nfields = 3)
>> Shall I send a bug report or is this a known problem?

> That happens for me on Unix.  If there is not already a bug report,
> send one.

The new version of chron (currently, 2.2-2) has added Y2K improvements
as described in file `Y2K' in the chron sources.  Roughly speaking, by
setting options appropriately, it is ensured that two-digit year abbrevs
continue to work ``correctly'' (using a cut-off mechanism to determine
the ``correct'' century).

Note that currently, chron/dates only supports formats like "m/d/y" or
"mdy" where all three signify (2-digit) abbreviations, or non-abbrev
formats such as "day mon year" where now month must be one of "Jan",
"Feb", etc. and corresponding versions with full month names.  A format
like yours, "d/m/Y" in strftime(3) notation, is not supported.

For example,

  as.numeric(dates("1 Jan 2000", format = "day mon year"))
  => 10957

as it should.

David James and I have had some conversation about improving chron.  For
him this is not necessarily high priority, as S-PLUS 5 has adopted their
own timeDate objects.  In R, we can either try implementing that, or
come up with a much improved chron, which would be my preference.  (As I
wrote yesterday, one idea is to use struct tm style representations for
chron objects.)  I will not get to this within the next few weeks
though ...

Meanwhile, it is always possible to write a function which parses the
given format correctly, and pass it on as the `format' argument.

r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch