> Why would a date function have
> a TZ? `as.Date` wouldn't.
This statement seems nonsensical to me. POSIXt objects have tzone attributes.
Date and chron objects do not. Since they do not include tzone, logically the
user should be able to supply it during a conversion from Date or chron to
POSIXt.
R is normally very good about distinguishing between a default value such as
zero (or "GMT") and undefined, and this "documented" behavior breaks that
consistency.
---------------------------------------------------------------------------
Jeff Newmiller The ..... ..... Go Live...
DCN:<jdnew...@dcn.davis.ca.us> Basics: ##.#. ##.#. Live Go...
Live: OO#.. Dead: OO#.. Playing
Research Engineer (Solar/Batteries O.O#. #.O#. with
/Software/Embedded Controllers) .OO#. .OO#. rocks...1k
---------------------------------------------------------------------------
Sent from my phone. Please excuse my brevity.
David Winsemius <dwinsem...@comcast.net> wrote:
>
>On Jun 15, 2012, at 11:18 PM, R. Michael Weylandt wrote:
>
>> It does seem that as.POSIXct.date doesn't respect the tz= argument
>the
>> generic suggests it would.
>
>Why would a date function have a TZ? `as.Date` wouldn't.
>
>> I'd think this is a bug that could be
>> changed without breaking back-compatibility, but I don't have the
>> power to make such things happen.
>
>What bug?
>
>Here is what ?chron says:
>
>"If x is character then it will be converted using as.POSIXct (with
>the format argument, if any, passed to as.POSIXct) and tz = "GMT" and
>then converted to chron. "
>
>So the call to `chron` below is using `as.POSIXct` first and then you
>will be looking at differences in the printing conventions for POSIXct
>
>and POSIXlt objects.
>
>And then in the as.POSIX (lt and ct ) help pages we read:
>
>"Character input is first converted to class "POSIXlt" by strptime:
>numeric input is first converted to "POSIXct". :
>
> > mode( chron('12/12/2000') )
>[1] "numeric"
>
>>
>> R-Core ruling?
>
>Er, not Core, just another useR.
>
>>
>> Michael
>>
>> On Fri, Jun 15, 2012 at 2:25 AM, Jannis <bt_jan...@yahoo.de> wrote:
>>> Hey R folks,
>>>
>>>
>>> i found some strange (to me) behaviour with chron to POSIXct
>>> conversion. The
>>> two lines of code result in two different results, on ewith the
>>> correct time
>>> zone, one without:
>>>
>>> library(chron)
>>> as.POSIXct(chron('12/12/2000'), tz = 'UTC')
>
> > format( as.POSIXct(chron('12/12/2000'), tz = 'UTC'), format="%Y-%m-
>%d %H:%M %Z")
>[1] "2000-12-11 19:00 EST"
>
>>> as.POSIXlt(chron('12/12/2000'), tz = 'UTC')
>
> > format( as.POSIXlt(chron('12/12/2000'), tz = 'UTC'), format="%Y-%m-
>%d %H:%M %Z")
>[1] "2000-12-12 00:00 UTC"
>
>These both look correct to me. (Different output conventions.)
>
> > as.POSIXct(chron('12/12/2000'), tz = 'UTC')
>[1] "2000-12-11 19:00:00 EST"
> > as.POSIXlt(chron('12/12/2000'), tz = 'UTC')
>[1] "2000-12-12 UTC"
>
>
>>>
>>> Only the code below would give me a POSIXct object with the correct
>
>>> time
>>> zone:
>>>
>>> as.POSIXct(as.POSIXlt(chron('12/12/2000'), tz = 'UTC'))
>
>I see the same output with that as I did with the second one:
>
> > as.POSIXct(as.POSIXlt(chron('12/12/2000'), tz = 'UTC'))
>[1] "2000-12-12 UTC"
>
>If you want to force printing in a particular TZ then use format (or
>strftime).
>
> > format(as.POSIXct(chron('12/12/2000'), tz = 'UTC'), tz="GMT",
>format="%Y-%m-%d %Z")
>[1] "2000-12-12 GMT"
>
>>>
>>>
>>> Is this a bug or desired behaviour?
>
>Jannis; You have not demonstrated what output you saw, so this is
>still a guessing game.
>
>
>
>--
>
>David Winsemius, MD
>West Hartford, CT
>
>______________________________________________
>R-help@r-project.org 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@r-project.org 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.
