Skip to content

Julian dates

4 messages · Massimiliano Tripoli, stefano iacus, (Ted Harding) +1 more

#
I guess there's a "bug" in chron as you cannot pass the argument cut.off to year.expand. Adding ,... in chron arguments and along the code ,... to convert.dates does the trick.

HIH,

Stefano
On Wed, Jan 28, 2004 at 11:50:11AM +0100, Massimiliano Tripoli wrote:
#
On 28-Jan-04 Massimiliano Tripoli wrote:
I'm puzzled by the above:
[1] 02/Jan/2029
[1] 02/Jan/1930

so chron apparently acts as though time began at 01/01/1930.

However:
-->
 origin.: a vector specifying the date with respect to which Julian
          dates are computed.  Default is 'c(month = 1, day = 1,
          year = 1970)'

(which is the orthodox origin of time according to Unix) and, indeed,
month   day  year 
    1     1  1970 

So why does Massimiliano's example behave as though the origin
were 01/01/1930?

Best wishes,
Ted.


--------------------------------------------------------------------
E-Mail: (Ted Harding) <Ted.Harding at nessie.mcc.ac.uk>
Fax-to-email: +44 (0)870 167 1972
Date: 28-Jan-04                                       Time: 16:38:37
------------------------------ XFMail ------------------------------
#
On Wed, 28 Jan 2004 Ted.Harding at nessie.mcc.ac.uk wrote:

            
It doesn't.  It behaves as if he wrote "01/02/2029" and he intended
"01/02/1929" (but chron failed to read his mind).  That is an undocumented
`feature' of the auxiliary function year.expand(), whose use is an
undocumented `feature' of convert.dates() (whose use is ..., well it gets
boring).

You will find all date-conversion routines do something like this with 
incompletely specified years.  Read the help on %y in ?strptime.