[Rd] inconsistency in POSIXlt

[Lorenz, David]

Gabriel,
  Thanks. I'm just frustrated by the inconsistencies in what I see in
POSIXlt. I'm not even sure what the tzone attribute does. Here's an example
that show behavior different from POSIXct.

> tl <- as.POSIXlt("2001-04-05 12:00", tz="America/Chicago")
> tl
[1] "2001-04-05 12:00:00 CDT"
> attr(tl, "tzone")
[1] "America/Chicago"
> attr(tl, "tzone") <- "America/Denver"
> tl
[1] "2001-04-05 12:00:00 CDT"
> tc <- as.POSIXct("2001-04-05 12:00", tz="America/Chicago")
> tc
[1] "2001-04-05 12:00:00 CDT"
> attr(tc, "tzone")
[1] "America/Chicago"
> attr(tc, "tzone") <- "America/Denver"
> tc
[1] "2001-04-05 11:00:00 MDT"

  From what I can see, changing the tzone attribute does nothing to the
display. But it does take effect when converting to POSIXct:

> as.POSIXct(tl)
[1] "2001-04-05 12:00:00 MDT"

  I think that was expected, knowing that POSIXlt is specifically local
time and if the tzone says Mountain time, then report in Mountain time. But
then what useful information is in the zone component in POSIXlt.



On Mon, Dec 7, 2015 at 3:23 PM, Gabriel Becker <gmbecker at ucdavis.edu> wrote:

> David,
>
> I didn't have time to dig through the code completely, but those other two
> are being set automatically in the C code as far as I can tell, in
> particular in the code
>
>     // localtime may change tzname.
>     if (isgmt) {
> 	PROTECT(tzone = mkString(tz));
>     } else {
> 	PROTECT(tzone = allocVector(STRSXP, 3));
> 	SET_STRING_ELT(tzone, 0, mkChar(tz));
> 	SET_STRING_ELT(tzone, 1, mkChar(R_tzname[0]));
> 	SET_STRING_ELT(tzone, 2, mkChar(R_tzname[1]));
>     }
>
>
> In the file https://svn.r-project.org/R/trunk/src/main/datetime.c (function do_asPOSIXlt)
>
> R_tzname is an extern char pointer. I can't say exactly where it is populated, but the code assumes it will be and that it will take care of what passing a length 3 vector would.
>
> Also, note that AFAICT the second and third are not freeform text, only very specific values are valid.
>
> Long story short, I think the answer is R doesn't let you do that because it takes care of it for you. (Unless someone more familiar with date handling in R pops in and points out how I've completely missed something).
>
> Best,
>
> ~G
>
>
> --
> Gabriel Becker, PhD
> Associate Scientist (Bioinformatics)
> Genentech Research
>

	[[alternative HTML version deleted]]