similar to: From POSIXct to numeric and back with time zone

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

Full_Name: Mario Luoni Version: 2.10.0 OS: Windows XP HE SP3 Submission from: (NULL) (217.194.59.134) 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: >

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

I'm reading in ~3 years worth of data that includes hourly timestamps. Presumably to avoid DST confusion, all the data is in PST time zone -- no discontinuities in the spring or fall. The data comes in a csv file, which I'm reading with myvariable <- read.csv("my_data_file.csv",header=FALSE,

Hi all, I am testing R 4.0 and ran into an issue with timezones on Ubuntu Focal: converting a timestamp to another timezone results in NA: as.POSIXct(as.POSIXlt(Sys.time(), tz = "CET"), tz = "EST") This only happens on Ubuntu Focal, it seems to work fine on Ubuntu Bionic. I am the standard ubuntu docker image icw/ r-base from Dirk's ppa:edd/r-4.0 on both systems. Am I

> 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

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

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

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

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

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

Colleagues I just installed 3.4.2 on a Mac running High Sierra. I encountered the following: R version 3.4.2 (2017-09-28) -- "Short Summer" Copyright (C) 2017 The R Foundation for Statistical Computing Platform: x86_64-apple-darwin15.6.0 (64-bit) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type

Hello, I use format() function to get number of the week, like this: format(tmp,'%U') Recently, I have spotted something bizarre. For example, I have such object: (index(tmp$x.delta['2009'][1:16])) [1] "2009-01-02 CET" "2009-01-09 CET" "2009-01-16 CET" "2009-01-23 CET" [5] "2009-01-30 CET" "2009-02-06 CET"

Greetings - I'm battling POSIXct, as per the code below. My input is actually an XL file, but the weird results below correctly model what I am seeing in my program. Before I punt and use lubridate or timeDate, could anyone please help me understand why POSIXct forces my variable back to GMT? I suspect that I'm not properly coding the tzone value, but it does not throw an

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

> x<-as.POSIXct("1970-1-1", tz="UTC")-.5 > y<-as.POSIXct("1970-1-1", tz="UTC")+.5 > x==y [1] FALSE # of course but x and y "appear" to be the same when formatted, even with extra precision: > format(x, format="%Y-%m-%d %H:%M:%OS2") [1] "1970-01-01 00:00:00.50" > format(y, format="%Y-%m-%d

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

Hi, As I didn't get any response on the general help list and I don't know if there is a bug in action I am trying my luck here. I was highly surprised to find out that during simple operations (see code below) the timezone attribute for POSIXct data is lost and then, upon the next interpretation, the system settings are used (which are plain wrong in my case). I have used R 2.8.0