similar to: Understanding POSIXct creation on different OSes.

Displaying 20 results from an estimated 10000 matches similar to: "Understanding POSIXct creation on different OSes."

2016 Apr 11
0
Understanding POSIXct creation on different OSes.
Bumping this up to the front again ... because it exhibits a difference in behaviour of R across OSs. Such a 'feature' may not be desirable. On 4 April 2016 at 18:00, Arunkumar Srinivasan wrote: | Hello, | | Following Dirk's post here: https://github.com/Rdatatable/data.table/issues/1619 | we would like to clarify if this is the right behaviour, and if so, | the rationale behind it.
2015 Jun 23
4
yum and yumex change system time
> Date: Tuesday, June 23, 2015 03:48:36 PM -0400 > From: Jonathan Billings <billings at negate.org> > > On Tue, Jun 23, 2015 at 01:56:13PM -0500, g wrote: >> each and every time i run yum or yumex, system time is advanced >> by 5 hours. >> >> this has gone on thru several updates, maybe even upgrades. >> >> centos = 6.6 current >> yum
2006 Oct 27
2
POSIXct time zone and daylight savings issues
Hello, Suppose we need a function that takes a POSIXct object and need to calculate the time difference between it and GMT time: gmtDiff <- function(time) { time.gmt <- as.POSIXct(format(time, tz="GMT")) time.plt <- as.POSIXlt(time) dlstime <- ifelse(time.plt$isdst > 0, 1, 0) timezone <- as.numeric(difftime(time, time.gmt, units="hours"))
2015 Jun 23
2
yum and yumex change system time
Richard, thank you for your response. On 06/23/2015 02:51 PM, Richard wrote: <<>> > I agree, so my questions are: > > - what is your TZ? u.s.a. 'central time zone' - currently on 'daylight savings time'. > - what does "[/bin/]date" show? [geo at boxen ~]$ date Tue Jun 23 14:54:42 CDT 2015 > - what does your hardware clock:
2009 Jan 28
2
length of POSIXlt object (PR#13482)
The length() of a POSIXlt object is given as 9 regardless of the actual length. For example: > make.date.time function (year=c(2006,2006),month=c(8,8),day=2:5,hour=13,minute=45) {# convert year, etc., into POSIXlt object # d=as.character(make.date(year,month,day)) t=paste(hour,minute,sep=":") as.POSIXlt(paste(d,t)) } > t=make.date.time() > t [1] "2006-08-02 13:45:00"
2009 Mar 04
2
patch for axis.POSIXct (related to timezones)
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
2013 Aug 22
1
From POSIXct to numeric and back with 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
2005 Oct 06
2
isdst
Can someone, please, explain the difference is results below (notice the isdst value) > unlist(as.POSIXlt('2005-7-1')) sec min hour mday mon year wday yday isdst 0 0 0 1 6 105 5 181 1 > unlist(as.POSIXlt(as.Date('2005-7-1'))) sec min hour mday mon year wday yday isdst 0 0 0 1 6 105 5 181 0
2020 Oct 01
3
timezone tests and R-devel
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
2002 May 21
1
I() fails on objects of class POSIXct (PR#1587)
Although the documentation is somewhat sketchy, I() can be used to create objects of class AsIs: > I("a") [1] "a" attr(,"class") [1] "AsIs" "character" > I(4) [1] 4 attr(,"class") [1] "AsIs" "numeric" > I(4 + 0i) [1] 4+0i attr(,"class") [1] "AsIs" "complex" > This
2010 Dec 27
1
Can't merge on datetime?
x = structure(list(date = structure(list(sec = c(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0), min = c(0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L), hour = c(0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L), mday = c(1L, 2L, 3L, 4L, 5L, 8L, 9L, 10L, 11L, 12L, 15L, 16L, 17L, 18L, 19L, 22L, 23L, 24L,
2012 Dec 06
1
Incorrect DST time changes in DateTimeClasses
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
2012 Sep 05
2
POSIXlt and daylight savings time
I have a data frame that contains dates, but when I use as.POSIXlt() I lose the hours on all records. I traced this down to a particuar hour which causes the issue... > as.POSIXlt('2004-10-31 02:00:00') [1] "2004-10-31" > as.POSIXlt('2004-10-31 03:00:00') [1] "2004-10-31 03:00:00" How do I tell as.POSIXlt() to ignore daylight savings and just convert to
2020 Oct 23
2
The presence/absence of `zone` in POSIXlt depending on time zone as a cause of possible inconsistences?
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 <-
2006 Jan 06
1
Daylight Savings Time unknown in R-2.2.1
Under R-2.2.1, a POSIXlt date created with "strptime" has an unknown Daylight Savings Time flag: > strptime(20051208, "%Y%m%d")$isdst [1] -1 This is true on both Linux (details below) and Windows. It did not occur under R-2.1.0. Any ideas? TIA! > Sys.getenv("TZ") TZ "" Version: platform = i686-pc-linux-gnu arch = i686 os = linux-gnu
2017 May 17
2
R-3.4.0 fails test
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" # =
2017 May 17
2
R-3.4.0 fails test
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" # =
2007 Dec 11
3
Wrong length of POSIXt vectors (PR#10507)
Full_Name: Petr Simecek Version: 2.5.1, 2.6.1 OS: Windows XP Submission from: (NULL) (195.113.231.2) Several times I have experienced that a length of a POSIXt vector has not been computed right. Example: tv<-structure(list(sec = c(50, 0, 55, 12, 2, 0, 37, NA, 17, 3, 31 ), min = c(1L, 10L, 11L, 15L, 16L, 18L, 18L, NA, 20L, 22L, 22L ), hour = c(12L, 12L, 12L, 12L, 12L, 12L, 12L, NA, 12L,
2020 Oct 02
2
timezone tests and 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
2006 Oct 12
2
plot.POSIXct
I've never had any issues with the way that plot.POSIXct chooses the labels of the date axis before, but in this particular case it's output is a little confusing. plot(seq(as.POSIXct("1997-10-01"),length.out=108,by="month"),rnorm(108)) This command produces a chart with every x tick mark labeled as "Jan 01". I can replicate this chart by adding the format