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 <rhelp at 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 at 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. >
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 <rhelp at 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 <rhelp at 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 at 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 at 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
? Thu, 10 Oct 2024 17:16:52 +0200 Jan van der Laan <rhelp at eoos.dds.nl> ?????:> 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.I think that since POSIXlt is an interface to what the C standard calls the "broken-down" time (into parts, not in terms of functionality) and both the C standard [1] and the POSIX mktime() [2] ignore the tm_gmtoff/tm_zone fields (standard C because it's not defined there; POSIX because it defers to standard C), these fields exist for presentation purposes. They may be populated when constructing the time object, but not used for later calculations. Instead, the standard mktime() always uses the process-global timezone, so when R processes POSIXlt values, it has to set the TZ environment variable from the 'tzone' attribute, call tzset() to set global state in the library, use mktime() to obtain seconds since epoch, and then reset everything back.> 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.Since your data looks like the following: 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") ) how about converting all the times into POSIXct? do.call(mapply, c( \(year, month, day, hour, minutes, seconds, timezone) "%04d-%02d-%02d %02d:%02d:%02d" |> sprintf(year, month, day, hour, minutes, seconds) |> as.POSIXct(format = "%Y-%m-%d %H:%M:%S", tz = timezone), times )) |> do.call(c, args=_) Its 'tzone' attribute exists mostly for presentation purposes, so even if you lose it, the exact point in UTC-relative time is still intact. -- Best regards, Ivan [1] https://en.cppreference.com/w/c/chrono/mktime [2] https://pubs.opengroup.org/onlinepubs/9799919799/functions/mktime.html