similar to: timezone attribute lost during operations

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

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

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

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 -

On Wed, 18 Oct 2017 18:09:41 +0200 Martin Maechler <maechler at stat.math.ethz.ch> wrote: >>>>>> Martin Maechler <maechler at stat.math.ethz.ch> >>>>>> on Mon, 16 Oct 2017 19:13:31 +0200 writes: (I also included a reply to part of this response of yours below.) >>>>>> Stephen Berman <stephen.berman at gmx.net>

>>>>> 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 the right one to address the issue; in the meantime I > investigated the matter somewhat more closely, including searching > recent R-devel

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

Full_Name: Suharto Anggono Version: 2.8.1 OS: Windows Submission from: (NULL) (125.165.84.118) PR#14076 inspired me to write this. > t1 <- as.POSIXct("1970-01-01 00:00:00", tz="GMT") > t2 <- as.POSIXlt("1970-01-01 00:00:00", tz="GMT") > t1 - t2 Time difference of 7 hours Above, t1 and t2 represent the same time in the same specified

>>>>> Stephen Berman <stephen.berman at gmx.net> >>>>> on Thu, 19 Oct 2017 17:12:50 +0200 writes: > On Wed, 18 Oct 2017 18:09:41 +0200 Martin Maechler <maechler at stat.math.ethz.ch> wrote: >>>>>>> Martin Maechler <maechler at stat.math.ethz.ch> >>>>>>> on Mon, 16 Oct 2017 19:13:31 +0200

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

It looks like a timezone issue, and it's causing confusion to me at least. My original data: gmt <- c("19880101 0000", "19880101 0100", "19880101 0300", "19880101 0400", "19880101 0500", "19880101 0600") These were converted to local dates/times with akst<-strptime(gmt,format="%Y%m%d %H%M")-(3600*9) # because I want

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

On 4/24/20 4:02 PM, Jeroen Ooms wrote: > 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

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

This is not a bug in R: the documentation does say the result is OS-specific. `GMT' is a not a proper timezone on Windows, so NA is a valid answer. (Windows seems to use GMT to refer to the timezone of the UK, e.g. > Sys.time() [1] "2005-07-11 07:49:56 GMT Daylight Time" > Sys.timezone() [1] "GMT Daylight Time" although I am in British Summer Time not GMT.)

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

the help page for plot.POSIXct says "As from R 2.9.0 the date-times for a '"POSIXct"' input are interpreted in the timwzonw give by the '"tzone"' attribute it there is one, otherwise the current timezone. (Earlier vrsions always used the current timezone.)" however I am using 2.9.0 on linux and the following still happily produces an

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) CHeers Joris On Thu, May 18, 2017 at 1:45 PM, Joris Meys <jorismeys at gmail.com> wrote: > This has to do with your own timezone. If I run

> On 18 May 2017, at 14:51, peter dalgaard <pdalgd at gmail.com> wrote: > > >> 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

(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