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')
as.POSIXlt(chron('12/12/2000'), tz = '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'))
Is this a bug or desired behaviour?
Thanks a lot
Jannis
time zones and the chron to POSIXct conversion
8 messages · Jannis, David Winsemius, Jeff Newmiller +2 more
It does seem that as.POSIXct.date doesn't respect the tz= argument the generic suggests it would. 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. R-Core ruling? Michael
On Fri, Jun 15, 2012 at 2:25 AM, Jannis <bt_jannis at 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')
as.POSIXlt(chron('12/12/2000'), tz = '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'))
Is this a bug or desired behaviour?
Thanks a lot
Jannis
______________________________________________ R-help at 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.
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_jannis at 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
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:<jdnewmil at 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 <dwinsemius at 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_jannis at 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 at 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.
On Fri, Jun 15, 2012 at 11:26 PM, David Winsemius
<dwinsemius at 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.
It seems that as.POSIXct.date and as.POSIXct.Date are different things here. I know that Date (capital) objects don't care tz properties -- I'm less clear on what comprises a "date" object here. There's also as.POSIXct.dates to be thrown in...
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"
"Bug" was admittedly too strong a word. Infelicity perhaps?
? as.POSIXct also says this:
tz: A timezone specification to be used for the conversion, _if
one is required_. System-specific (see time zones), but ?""?
is the current timezone, and ?"GMT"? is UTC (Universal Time,
Coordinated).
So R-Core doesn't have a problem with it being ignored. What I'm not
clear on is what exactly that means -- is the tz= argument a property
of the input or the output? Looking around, I can't see a super clear
pattern:
as.POSIXct.Date, as.POSIXct.date, and as.POSIXct.dates all ignore it
as.POSIXct.POSIXlt seems to pass it to .POSIXct which associates it
with the output
as.POSIXct.numeric seems to pass it to as.POSIXct but alongside the
origin (which is a sort of input)
ISOdatetime suggests it's both in and out.
It seems contrary to WRE 7.0 which says "Only add parameters and
defaults to the generic if they make sense in all possible methods
implementing it." I see some reason to each choice individually, but
the sum total doesn't emerge so naturally. My intuition for the
[Dd]ate(s) would have been something like what Jeff expressed
upthread.
Now that I've said my peace and looked at it more, I think I do
retract my earlier objection: my assumptions about what the tz=
argument would do were incorrect and I had not properly checked them
against the documentation and the source code.
My apologies to all for the noise and my continued thanks to R-Core
for their great gift to our little corner of the computing world.
Michael
R-Core ruling?
Er, not Core, just another useR.
Michael On Fri, Jun 15, 2012 at 2:25 AM, Jannis <bt_jannis at 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
On Jun 16, 2012, at 1:01 AM, Jeff Newmiller wrote:
Why would a date function have a TZ? `as.Date` wouldn't.
This statement seems nonsensical to me. POSIXt objects have tzone attributes.
They do?
David.
> 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:<jdnewmil at 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 <dwinsemius at 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_jannis at 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 at 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.
>
David Winsemius, MD
West Hartford, CT
On Jun 16, 2012, at 1:01 AM, Jeff Newmiller wrote:
Why would a date function have a TZ? `as.Date` wouldn't.
This statement seems nonsensical to me. POSIXt objects have tzone attributes.
I earlier expressed surprise at this statement based on:
attributes(as.POSIXct(chron('12/12/2000'), tz = 'UTC'))
$class
[1] "POSIXct" "POSIXt"
> attributes(as.POSIXct(as.Date('12/12/2000', format="%m/%d/%Y")))
$class
[1] "POSIXct" "POSIXt"
I see now that it is one of those "sometimes they do" cases:
> attributes(ISOdate(2001,12,24))
$class
[1] "POSIXct" "POSIXt"
$tzone
[1] "GMT"
David.
> 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:<jdnewmil at 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 <dwinsemius at 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_jannis at 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 at 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.
>
David Winsemius, MD
West Hartford, CT
On Fri, Jun 15, 2012 at 3:25 AM, Jannis <bt_jannis at 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')
as.POSIXlt(chron('12/12/2000'), tz = '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'))
Is this a bug or desired behaviour?
The time zone aspect of these conversions can be tricky and its generally safer to convert to a character representation first and then from there convert to the desired class. Here we first convert it to Date class since Date's default character format is similar to POSIXct's and then convert to character. Note that up to this point it does not involve time zones. Finally we apply as.POSIXct.
cc <- chron("12/12/2000")
as.POSIXct(format(as.Date(cc)), tz = "UTC")
[1] "2000-12-12 UTC" There is a table at the end of the help desk article of R News 4/1 which shows how to do various conversions between various classes. Although the article is quite old most of it still works. There is also some question here of whether POSIXct is really the appropriate class in the first place. Suggest you read the aforementioned article for some pointers on that.
Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com