[R] Extent of time zone vulerability for POSIX date and time classes

Tim Bergsma timb at metrumrg.com
Thu Apr 5 19:32:26 CEST 2007


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 <timb at metrumrg.com> 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 <timb at metrumrg.com> 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 at 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.
>> >>
>> >
>> >
>>
> 
>



More information about the R-help mailing list