similar to: Typo in DateTimeClasses.Rd

Hello, In my previous e-mail I forgot the link to the thread I mention. [1] https://stat.ethz.ch/pipermail/r-help/2024-October/480098.html Sorry for the mess, Rui Barradas -- Este e-mail foi analisado pelo software antiv?rus AVG para verificar a presen?a de v?rus. www.avg.com

Can anyone please shed any light on why R DateTimeClasses give weird times for when daylight saving time information changes, and which aren't consistent with the OS? Example: Expected result: in New Zealand DST stopped (NZDT -> NZST) at 03:00 NZDT on 2010-04-04, as confirmed by the OS time zone info (OS X 10.8.2): zdump -v /etc/localtime /etc/localtime Sat Apr 3 13:59:59 2010 UTC

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

I am sorry to reply. But I need to clarify things.=0A=0AFrom searching over= the internet, I know that, before R 2.5.0, in the documentation of 'DateTi= meClasses', in 'date + x', in the explanation about 'x', there is also ment= ion that 'x' can be a 'difftime' object. Now, it has been removed.=0A=0AWhy= not doing the same in the documentation of

?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

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

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

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

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

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

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

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

Hello R List - I have to import Excel files (either as .csv files or using RODBC) into R (2.4.1, Windows) and operate on dates and times (e.g. find minutes between times, change dates to days of week or analyze by weeks of year). The help files for format.Date, strptime, as.POSIX, DateTimeClasses, etc. etc. are informative but perhaps a little terse. I have googled unsuccessfully for a more

On the help page "DateTimeClasses {base}" it says: "One can add or subtract a number of seconds or a difftime object from a date-time object, but not add two date-time objects." However, > x<-Sys.time(); y<-Sys.time()+3600 > diff<-y-x > x; y; diff [1] "2005-11-23 19:58:20 GMT" [1] "2005-11-23 20:58:20 GMT" Time difference of 1 hours

What is the recommended class for time of day (independent of calendar date)? And what is the recommended way to get the time of day from a POSIXct object? (Not a string representation, but a computable representation.) I have looked in the man page for DateTimeClasses, in the Time Series Analysis Task View and in Spector's Data Manipulation book but haven't found these. Clearly I can

> (1) Create a top-level help page with a title like "Date and Time > Classes" to give a brief but general overview. This would mean the > existing DateTimeClasses would need a new title. I wanted to modify my first suggestion. Perhaps a better idea would be to reference an external document giving an overview of the subject. I couldn't find a discussion of POSIXct/POSIXlt

I've been searching for patterns in why some POSIXlt objects have the zone and gmtoff components and some don't and why gmtoff is sometimes NA when the zone is known. Is there a pattern or is it just that the additional fields and workarounds were added in an ad hoc way? E.g., as.POSIXlt adds the zone and gmtoff components for all strings and logical NA inputs if the time zone is not

I read a few days back on the list where the tzdata rpm was to take care of the new DST rules. I run CentOS 3 servers, and did a 'yum update tzdata' , but received a 2006a update of the rpm. Is this proper? It sure didn't fix anything. Thanks Steve Campbell campbell at cnpapers.com Charleston Newspapers

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