similar to: Time zones in POSIClt objects

POSIXt vectors do not support different time zones element-to-element. 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. I complained about

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

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

?s 15:13 de 10/10/2024, Jeff Newmiller via R-help escreveu: > POSIXt vectors do not support different time zones element-to-element. > > 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

? 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

The return value of Sys.time() today with a timezone of US/Eastern is unchanged between 4.0.3-patched and devel, but on devel the following test fails all.equal(x, as.POSIXlt(x)) with x = Sys.time() This means that devel does not complete make tests (failure on tests/reg-tests-2.R) It is entirely possible that it is an error on my end, I use export TZ="US/Eastern" but I have been

Yes, the potential issue I see is that make check fails when I explicitly set TZ. However, I set it to be the same as what the system reports when I login. Details: The system (RHEL) I am working on has $ strings /etc/localtime | tail -n 1 EST5EDT,M3.2.0,M11.1.0 $ date +%Z EDT $ echo $TZ US/Eastern On Fri, Oct 2, 2020 at 9:48 AM Sebastian Meyer <seb.meyer at fau.de> wrote: > Thank

After installing R-3.4.0 I ran 'make check' which halted here: $ > tail reg-tests-1d.Rout.fail -n 16 > ## format()ing invalid hand-constructed POSIXlt objects > d <- as.POSIXlt("2016-12-06"); d$zone <- 1 > tools::assertError(format(d)) > d$zone <- NULL > stopifnot(identical(format(d),"2016-12-06")) > d$zone <- "CET" # =

After installing R-3.4.0 I ran 'make check' which halted here: $ > tail reg-tests-1d.Rout.fail -n 16 > ## format()ing invalid hand-constructed POSIXlt objects > d <- as.POSIXlt("2016-12-06"); d$zone <- 1 > tools::assertError(format(d)) > d$zone <- NULL > stopifnot(identical(format(d),"2016-12-06")) > d$zone <- "CET" # =

Dear all, I have just detected what seems a minor inconsistence with data types. If one unlists a POSIXlt time with GMT zone gets a numeric vector, since the POSIXlt list has no `zone` element, while if one unlists a POSIXlt time with a non GMT zone (also non specifying tz if the Sys.timezone is not GMT) gets a character vector due to including the `zone` element. > x <-

This has to do with your own timezone. If I run that code on my computer, both formats are correct. If I do this after Sys.setenv(TZ = "UTC") Then: > cbind(format(dlt), format(dct)) [,1] [,2] [1,] "2016-12-06 21:45:41" "2016-12-06 20:45:41" [2,] "2016-12-06 21:45:42" "2016-12-06 20:45:42" The reason for that, is that

> On 18 May 2017, at 13:47 , Joris Meys <jorismeys at gmail.com> wrote: > > Correction: Also dlt uses the default timezone, but POSIXlt is not recalculated whereas POSIXct is. Reason for that is the different way values are stored (hours, minutes, seconds as opposed to minutes from origin, as explained in my previous mail) > I would suspect that there is something more subtle

On Wed, 17-May-2017 at 01:21PM +0200, Peter Dalgaard wrote: |> |> Anyways, you might want to |> |> a) move the discussion to R-devel |> b) include your platform (hardware, OS) and time zone info System: Host: MTA-V1-427894 Kernel: 3.19.0-32-generic x86_64 (64 bit gcc: 4.8.2) Desktop: KDE Plasma 4.14.2 (Qt 4.8.6) Distro: Linux Mint 17.3 Rosa Machine: System:

Yes, you are absolutely right and I'm pretty sure this will be fixed in one way or another. IMO, the failing test should simply use all.equal.POSIXt's new argument check.tzone=FALSE. Two simple alternatives modifying all.equal.POSIXt behaviour: - make check.tzone=FALSE the default: this is inconsistent with other arguments of all.equal methods, always defaulting to stricter checks -

?Hi again, I take advantage of my previous mail to ask you a question for which I was looking for an answer when detected the behaviour I previously told. In the help of DataTimeClasses one can read: "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

Thank you for the report. In R-devel, all.equal.POSIXt() by default reports inconsistent time zones. Previously, > x <- Sys.time() > all.equal(x, as.POSIXlt(x, tz = "EST5EDT")) would return TRUE. To ignore the time zone attributes in R-devel, the argument 'check.tzone = FALSE' needs to be used. That said, I can reproduce the 'make check' failure in R-devel on

Hi Joshua, Thank you for minimizing my test case. > > Hope I'm not doing something illegal... > > > You are. You're changing the internal structure of a POSIXlt object > by re-ordering the list elements. You should not expect a malformed > POSIXlt object to behave as if it's correctly formed. You can see > it's malformed by comparing it's

So let me try to raise this issue once more, and perhaps be more clear about what I think the issue is.. In my opinion there is now a bug in make check in R-development (tested today with r79361). As I see it, I specify a reasonable TZ environment variable and this leads to make check emitting an error. Best, Kasper On Fri, Oct 2, 2020 at 11:28 AM Kasper Daniel Hansen < kasperdanielhansen

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

I am finding that axis.POSIXct uses the local timezone for deciding where to put tic marks, even if the data being plotted are in another time zone. The solution is to use attr() to copy from the 'x' (provided as an argument) to the 'z' (used for the 'at' locations). I have pasted my proposed solution in section 1 below (as a diff). Then, in section 2, I'll put some