similar to: c(a, b) for POSIXct objects with tzone attributes?

Displaying 20 results from an estimated 5000 matches similar to: "c(a, b) for POSIXct objects with tzone attributes?"

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
2011 May 31
3
DateTime Math in R - POSIXct
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
2004 Aug 19
2
proposed change to [.POSIXct
R developers, The "tzone" attribute is stripped from a POSIXct object when the subscript command is called ("[.POISXct"). This results in dates being printed in the locale specific format after a subscript operation is applied to a POSIXct object which has cause several problems for me in the past. Here is an example of this problem under R 1.9.1: > x <-
2018 Mar 26
1
Typo in src/extra/tzone/registryTZ.c
I stumbled upon a typo in a time zone name: Irtutsk should be Irkutsk. A patch is attached. I also checked that this is the only bug of its kind in this file, i.e., all the other Olson time zones occurring in the file can also be found in Unicode Common Locale Data Repository. - Mikko Korpela Index: src/extra/tzone/registryTZ.c ===================================================================
2011 Feb 11
2
tzone and DST
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,
2010 Jan 12
0
Wishlist: Function 'difftime' to honor 'tzone' attribute (PR#14182)
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
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
2008 Feb 16
3
Arithmetic bug? (found when use POSIXct) (PR#10776)
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()
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
2012 Oct 30
2
POSIXct date missing "time component"
Hi, I have some dates that are giving me a problem, in general the dates look like this: free.dates[60:61] [1] "2009-05-21 23:45:00 GMT" "2009-05-22 00:00:00 GMT" but for some reason, when taken "alone", they look like this: free.dates[60] [1] "2009-05-21 23:45:00 GMT" free.dates[61] [1] "2009-05-22 GMT" # the time component is gone, and
2011 Jan 07
1
POSIXct issue
Hello I have trouble getting my original datetime back see below. I hope I am missing something. Please help. > tt <- as.POSIXct("2011-01-07 07:49:13", tz="EST") > tt [1] "2011-01-07 07:49:13 EST" > ttn <- as.numeric(tt) > ttn [1] 1294404553 > tt <- as.POSIXct(ttn,origin='1970-01-01',tz="EST") > tt [1] "2011-01-07
2010 Jun 14
1
Subtracting POSIXct data/times
I have two dataframe columns of POXIXct data/times that include seconds. I got them into this format using for example zsort$ETA <- as.POSIXct(as.character(zsort$ETA), format="%m/%d/%Y %H:%M:%S") My problem is that when I subtract the two columns, sometimes the difference is given in seconds, and sometimes it is given in minutes. I don't care which it is, but I need to know which
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
2007 Apr 04
1
time zone problems
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
2015 Dec 07
2
inconsistency in POSIXlt
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
2024 Oct 10
1
Time zones in POSIClt objects
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
2012 Aug 09
1
POSIXct to ts
Hi, I have a dataframe (try.1) with  date/time and temperature columns, and the date/time is in POSIXct fomat. Sample included below. I would like to to try decompose () or stl() to look at the trends and seasonality in my data, eventually so that  I can  look at autocorrelation.  The series is 3 years of water temperature with clearly visible seasonal periods. Right now, if I try decompose,
2024 Oct 10
2
Time zones in POSIClt objects
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
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
2010 Sep 03
1
Incorrect formatted output after subtracting non-integer seconds from POSIXt origin
> 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