R devel - Dec 2015 - inconsistency in POSIXlt

The documentation for the POSIXlt class states '"POSIXlt" objects
will
often have an attribute "tzone", a character vector of length 3 giving
the
time zone name from the TZ environment variable and the names of the base
time zone and the alternate (daylight-saving) time zone. Sometimes this may
just be of length one, giving the time zone
<http://127.0.0.1:25207/library/base/help/time%20zone> name.' But the
 constructor for the class, as.POSIXlt, accepts only a single value for the
tz argument--an error is generated if, for example the tzone value of
length 3 is extracted from a POSIXlt object and used as the tz argument.

It would seem to me that to be consistent, the as.POSIXlt function should
accept a vector of length 3 as the tz argument.

	[[alternative HTML version deleted]]

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]]

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]]