Gabor, The out.fmt approach seems optimal. Thank you!
Tim. Gabor Grothendieck wrote: > There are several ways: > > 1. the default number of year digits is set by the chron.year.abb option. > The R News article mentions this in the Avoiding Errors section but > does suggest you not set it. > > options(chron.year.abb = FALSE) > chron(1) > > 2. Alternately, define: > > out.fmt <- function(x) with( month.day.year(x), > sprintf("%02.f/%02.f/%04.f", month, day, year)) > > # Now any of these will work: > x <- chron(1:5) > out.fmt(x) > > # or > > x <- chron(1:5) > chron(x, out.format = out.fmt) > > # or > > x <- chron(1:5, out.format = out.fmt) > x > > > On 4/5/07, Tim Bergsma <[EMAIL PROTECTED]> wrote: >> Gabor, >> >> thanks for the feedback. I like the idea of coercing the system time >> zone, and sticking with strptime/strftime. The balance would probably >> tip in favor of chron, however, if I could get the format correct. >> Apparently the default is two-digit year: >> >> library(chron) >> chron(1) >> [1] 01/02/70 >> >> chron(1,format="m/d/y") >> [1] 01/02/70 >> >> But I need four digit year, so I try: >> >> chron(1,format="m/d/yyyy") >> [1] Jan/02/1970 >> >> Now, month has switched to character! I don't know of a format >> convention that gets it back to numeric (although conventions are >> documented for forcing to character). Comment? >> >> Regards, >> >> Tim. >> >> >> Gabor Grothendieck wrote: >> > If you use >> > >> > Sys.putenv(TZ = "GMT") >> > >> > at the beginning of your session then local time zone and GMT time >> > zone will be the same so you should not have a problem. This was >> > not possible, at least on Windows, at the time the R News article >> > was written. >> > >> > >> > >> > >> > >> > On 4/5/07, Tim Bergsma <[EMAIL PROTECTED]> wrote: >> >> Hi. >> >> >> >> I frequently convert date and time data to and from character >> >> representations. I'm frustrated with chron, because 'seconds' are >> >> required to create a time object (my input data never has seconds). >> > >> > You could use paste: >> > >> > times(paste("12:30", 0, sep = ":")) >> > >> > and make it into a function if you use it a lot. >> > >> >> More importantly, I cannot make chron print the format 12/30/2006 >> (which >> >> my output data requires). >> > >> > That is the default output format so you don't have to specify >> anything. >> > Its >> > only with POSIX that its not the default. For example: >> > >> >> library(chron) >> >> x <- chron("12/30/2006") >> >> x >> > [1] 12/30/06 >> > >> >> >> >> I really like the format flexibility of strftime() and strptime(), but >> >> of course am paranoid about timezone issues. After reading the >> standard >> >> reference several times >> >> (http://cran.r-project.org/doc/Rnews/Rnews_2004-1.pdf), I am >> tempted to >> >> conclude that if I never specify timezones, and never use Sys.time(), >> >> the vulnerabilities do not pertain. >> > >> > That won't protect you but this would let you use POSIX safely: >> > >> > http://www.mail-archive.com/r-help@stat.math.ethz.ch/msg83508.html >> > >> >> >> >> To the point: if I'm merely converting to and from character data that >> >> does not represent time zones, is there still a time zone >> vulnerability >> >> with strftime() and strptime()? >> >> >> >> Thanks in advance, >> >> >> >> Tim Bergsma, PhD >> >> Metrum Research Group, LLC >> >> >> >> >> >> #example >> >> strftime( >> >> strptime( >> >> "30-Dec-06 23:30", >> >> format="%d-%b-%y %H:%M" >> >> ), >> >> format="%m/%d/%Y %H:%M" >> >> ) >> >> [1] "12/30/2006 23:30" >> >> >> >> ______________________________________________ >> >> R-help@stat.math.ethz.ch mailing list >> >> https://stat.ethz.ch/mailman/listinfo/r-help >> >> PLEASE do read the posting guide >> >> http://www.R-project.org/posting-guide.html >> >> and provide commented, minimal, self-contained, reproducible code. >> >> >> > >> > >> > > ______________________________________________ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.