similar to: as.Date function yields inconsistent results (PR#14166)

All! This piece of code: zzz1 <- as.POSIXct("1999-03-18", tz="CET") zzz2 <- as.POSIXlt("1999-03-18", tz="CET") zzz1 == zzz2 as.Date(zzz1) as.Date(zzz2) yields TRUE for "zzz1==zzz2", but the two dates returned by as.Date are different: > as.Date(zzz1) [1] "1999-03-17" > as.Date(zzz2) [1] "1999-03-18" I'm

Hi all; I've already send a similar e-mail to the list and Prof. Brian Ripley answered me but my doubts remain unresolved. Thanks for the clarification, but perhaps I wasn't clear enough in posting my questions. I've got a postgres database which I read into R. The first column is Timestamp with timezone, and my data are already in UTC format. An 'printed' extract of R

Full_Name: Bo Zhou Version: 2.6.1 (2007-11-26) OS: Windows XP Submission from: (NULL) (207.237.54.242) Hi, I found an arithmetic problem when I'm doing something with POSIXct The code to reproduce it is as follows (This is the recommended way of finding out time zone difference on R News 2004-1 Page 32 URL http://cran.r-project.org/doc/Rnews/Rnews_2004-1.pdf) a=Sys.time()

guestfish --ro -a /path/to/disk run : mount /dev/your-blkdev / : download /etc/resolv.conf /path/on/host/dst.file -- +380979184774 Mykola Ivanets пт, 28 черв. 2019 о 21:29 Nikolay Ivanets <stenavin@gmail.com> пише: > > All API is exposed as gustfish commands > > -- > Mykola Ivanets > > пт, 28 черв. 2019, 21:28 користувач Chintan Patel

Folks, I'm having trouble with how datetime objects with time zones are set and plotted. This may be the result of my running R (2.4.0) on a Windoze XP box. Perhaps not. Here are two example problems I need advise on if you have time: 1) I collect data with dates (often as a fractional day of year) in UTC. Using strptime to create date time objects appears to force the data 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

>>>>> Martin Maechler <maechler at stat.math.ethz.ch> >>>>> on Mon, 16 Oct 2017 19:13:31 +0200 writes: >>>>> Stephen Berman <stephen.berman at gmx.net> >>>>> on Sun, 15 Oct 2017 01:53:12 +0200 writes: > > (I reported the test failure mentioned below to R-help but was advised > > that this list is

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

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

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" # =

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

(I reported the test failure mentioned below to R-help but was advised that this list is the right one to address the issue; in the meantime I investigated the matter somewhat more closely, including searching recent R-devel postings, since I haven't been following this list.) Last May there were two reports here of problems with Sys.timezone, one where the zoneinfo directory is in a

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

? 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

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

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

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

From POSIXct to numeric and back with time zone I am running regressions on data which has time series with different time resolution. Some data has hourly resolution, while most has either daily or weekly resolution. Aggregation is used to make the hourly data daily, while liner interpolation is used to find daily data from the weekly time series. This data manipulation requires some careful