Sys.setenv(TZ = "GMT") will set the local time zone to GMT so there
would only be one time
zone regardless of whether local or GMT were used.
On Thu, Oct 10, 2024 at 11:17 AM Jan van der Laan <rh...@eoos.dds.nl> wrote:
>
> Thanks.
>
> On 10/10/24 16:13, Jeff Newmiller wrote:
> > POSIXt vectors do not support different time zones element-to-element.
>
> > I complained about this on this list a couple of decades ago, and was
> chastised for it. Evidently handling timezones per element was
> considered to be too impractically slow to be a standard feature.
>
>
> This is where it is unclear to me what the purpose is of the `zone`
> element of the POSIXlt object. It does allow for registering a time zone
> per element. It just seems to be ignored.
>
> >
> > If you want to keep track of timezones per element, you have to create a
> > vector of timestamps (I would recommend POSIXct using UTC) and a parallel
> > vector of timezone strings. How you manipulate these depends on your use
> > cases, but from R's perspective you will have to manipulate them
> > element-by-element.
>
> As I mentioned, fortunately, I only have local time and GMT and it would
> be fine to convert them to a single time zone if that is what it takes
> to work with them in R. So, I guess, I could split the vector in two,
> convert local time to GMT and combine them again (respecting the
> original order).
>
> Jan
>
>
>
>
> > On October 10, 2024 6:46:19 AM PDT, Jan van der Laan <rh...@eoos.dds.nl>
> > wrote:
> >>
> >> It is not completely clear to me how time zones work with POSIXlt objects.
> >> For POSIXct, I can understand what happens: time is always stored in GMT,
> >> the `tzone` attribute only affects how the times are displayed. All
> >> computations etc. are done in GMT.
> >>
> >> POSIXlt objects have both a `tzone` attribute and a `zone` field. It seems
> >> that the `zone` field is largely ignored. It only seems to be used for
> >> displaying the times, but does not seem to play a role when doing
> >> arithmetic and conversions of the times.
> >>
> >> For example below, we have the same times in two different time zones. The
> >> following seems to do what I expect: when we subtract the two times we get
> >> the difference in time between the two time zones:
> >>
> >> t1 <- as.POSIXlt(c("2024-01-01 12:30", "2024-01-01 12:30"), tz = "GMT")
> >> t1$zone
> >> # [1] "GMT" "GMT"
> >>
> >> t2 <- as.POSIXlt(c("2024-01-01 12:30", "2024-01-01 12:30"))
> >> t2$zone
> >> # [1] "CET" "CET"
> >>
> >> t1 - t2
> >> # Time differences in hours
> >> # [1] 1 1
> >>
> >>
> >> When I change the `tzone` attribute of t1 to that of t2:
> >>
> >> attr(t1, "tzone") <- attr(t2, "tzone")
> >> t1
> >> #[1] "2024-01-01 12:30:00 GMT" "2024-01-01 12:30:00 GMT"
> >>
> >> The times are still displayed as being in GMT, however when I take the
> >> difference:
> >>
> >> t1 - t2
> >> #Time differences in secs
> >> #[1] 0 0
> >>
> >> We get a difference of 0. So it seems that the difference is only based on
> >> the `tzone` attribute. The value of `zone` is completely ignored.
> >>
> >> I am aware of the following remark in ?POSIXlt on arithmetic operations
> >> | Be aware that ‘"POSIXlt"’ objects will be interpreted as being in
> >> | the current time zone for these operations unless a time zone has
> >> | been specified.
> >>
> >> but this does not explain this, I think.
> >>
> >> One of the reasons, I ask, is that I have (potentially) times in different
> >> time zones. Using POXIXlt objects seems like they could store/support
> >> this. But working with this seems unpractical as the `zone` field does not
> >> seem to do anything:
> >>
> >> t1$zone <- c("CET", "GMT")
> >> t1 - t2
> >> #Time differences in secs
> >> #[1] 0 0
> >>
> >> Also the `gmtoff` field does not seem to do anything. For what/where is
> >> this field used?
> >>
> >> t1$gmtoff <- c(3600, 0)
> >> t1
> >> #[1] "2024-01-01 12:30:00 CET" "2024-01-01 12:30:00 GMT"
> >>
> >> t1 - t2
> >> #Time differences in secs
> >> #[1] 0 0
> >>
> >> as.POSIXct(t1)
> >> #[1] "2024-01-01 12:30:00 CET" "2024-01-01 12:30:00 CET"
> >>
> >> So, I am not sure what purpose the zone and gmtoff fields have. Do they
> >> have a purpose? Am I using them wrong? The reason I am asking, is that I
> >> have some times in potentially different time zones. The data I get is
> >> something like:
> >>
> >> times <- list(
> >> year = c(2024L, 2024L),
> >> month = c(1L, 1L),
> >> day = c(1L, 1L),
> >> hour = c(12L, 12L),
> >> minutes = c(30L, 30L),
> >> seconds = c(0, 0),
> >> timezone = c("", "GMT")
> >> )
> >>
> >> I am looking for ways to convert this into a practical date format for
> >> working with in R. Possible time zones are only local time or UTC/GMT. I
> >> would be fine with either converting local time to GMT. What would be a
> >> good way to convert these to a format R can work with?
> >>
> >> Thanks for the help.
> >>
> >> Jan
> >>
> >> ______________________________________________
> >> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> >> https://stat.ethz.ch/mailman/listinfo/r-help
> >> PLEASE do read the posting guide
> >> https://www.R-project.org/posting-guide.html
> >> and provide commented, minimal, self-contained, reproducible code.
> >
>
> ______________________________________________
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide https://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
______________________________________________
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide https://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
