Hi,
For a project I try to keep everything in normal time, not daylight saving time, to prevent problem when instruments collected data during the nights when we go from DST to normal time.
But sometimes R tricks me and I do not know how to prevent it.
This is one example:
lights_on = as.POSIXct(c("2011-05-06 04:09:26", "2011-05-07 04:07:53", "2011-05-08 04:06:21",
"2011-05-09 04:04:51", "2011-05-10 04:03:22", "2011-05-11 04:01:55",
"2011-05-12 04:00:30", "2011-05-13 03:59:06", "2011-05-14 03:57:45",
"2011-05-15 03:56:25", "2011-05-16 03:55:07"), tz="EST") # not DST
lights_off = as.POSIXct(c("2011-05-05 18:56:54", "2011-05-06 18:58:19", "2011-05-07 18:59:44",
"2011-05-08 19:01:08", "2011-05-09 19:02:32", "2011-05-10 19:03:55",
"2011-05-11 19:05:18", "2011-05-12 19:06:40", "2011-05-13 19:08:01",
"2011-05-14 19:09:22", "2011-05-15 19:10:42" ), tz="EST") # not DST
(a = lights_on[c(1,5)]) # not DST
[1] "2011-05-06 04:09:26 EST" "2011-05-10 04:03:22 EST"
(b = lights_off[c(2,6)]) # not DST
[1] "2011-05-06 18:58:19 EST" "2011-05-10 19:03:55 EST"
(x = c(lights_off[2], lights_on[2])) # suddenly DST
[1] "2011-05-06 19:58:19 EDT" "2011-05-07 05:07:53 EDT"
Why did x end up in DST? How could I prevent it?
Thanks in advance,
Denis
unwanted switch to DST with POSIXct objects
4 messages · Denis Chabot, Jeff Newmiller, Spencer Graves
An embedded and charset-unspecified text was scrubbed... Name: not available URL: <https://stat.ethz.ch/pipermail/r-help/attachments/20110605/ad47d0b2/attachment.pl>
On 6/5/2011 9:30 AM, Jeff Newmiller wrote:
Sys.setenv(TZ="Etc/GMT+5")
Or:
x <- as.POSIXct(as.Date('2011-01-15'))
attr(x, 'tzone') <- "Etc/GMT+5"
x
This version works without Sys.setenv, which may not work on some
platforms. Unfortunately, I believe there are some copy operations that
lose attributes like tzone, so you need to check.
For some of the most advanced and complicated time series
problems, you might consider what's available from the Rmetrics project,
e.g., at "https://www.rmetrics.org/ebooks": They are designed to deal
with coordinating trading data from financial markets all over the
world, each of which affects all the others but have different trading
hours.
Hope this helps.
Spencer
Make the timezone you prefer the default for that R session.
FWIW: EST may or may not exist as a valid timezone on your system, but it is an ambiguous notation anyway.
---------------------------------------------------------------------------
Jeff Newmiller The ..... ..... Go Live...
DCN:<jdnewmil at dcn.davis.ca.us> Basics: ##.#. ##.#. Live Go...
Live: OO#.. Dead: OO#.. Playing
Research Engineer (Solar/Batteries O.O#. #.O#. with
/Software/Embedded Controllers) .OO#. .OO#. rocks...1k
---------------------------------------------------------------------------
Sent from my phone. Please excuse my brevity.
Denis Chabot<chabot.denis at gmail.com> wrote:
Hi,
For a project I try to keep everything in normal time, not daylight saving time, to prevent problem when instruments collected data during the nights when we go from DST to normal time.
But sometimes R tricks me and I do not know how to prevent it.
This is one example:
lights_on = as.POSIXct(c("2011-05-06 04:09:26", "2011-05-07 04:07:53", "2011-05-08 04:06:21",
"2011-05-09 04:04:51", "2011-05-10 04:03:22", "2011-05-11 04:01:55",
"2011-05-12 04:00:30", "2011-05-13 03:59:06", "2011-05-14 03:57:45",
"2011-05-15 03:56:25", "2011-05-16 03:55:07"), tz="EST") # not DST
lights_off = as.POSIXct(c("2011-05-05 18:56:54", "2011-05-06 18:58:19", "2011-05-07 18:59:44",
"2011-05-08 19:01:08", "2011-05-09 19:02:32", "2011-05-10 19:03:55",
"2011-05-11 19:05:18", "2011-05-12 19:06:40", "2011-05-13 19:08:01",
"2011-05-14 19:09:22", "2011-05-15 19:10:42" ), tz="EST") # not DST
(a = lights_on[c(1,5)]) # not DST
[1] "2011-05-06 04:09:26 EST" "2011-05-10 04:03:22 EST"
(b = lights_off[c(2,6)]) # not DST
[1] "2011-05-06 18:58:19 EST" "2011-05-10 19:03:55 EST"
(x = c(lights_off[2], lights_on[2])) # suddenly DST
[1] "2011-05-06 19:58:19 EDT" "2011-05-07 05:07:53 EDT"
Why did x end up in DST? How could I prevent it?
Thanks in advance,
Denis
_____________________________________________ R-help at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. [[alternative HTML version deleted]] ______________________________________________ R-help at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Spencer Graves, PE, PhD President and Chief Operating Officer Structure Inspection and Monitoring, Inc. 751 Emerson Ct. San Jos?, CA 95126 ph: 408-655-4567
Thanks Jeff and Spencer, I will probably set the time zone for my session, but I had forgotten the possibility of setting the time zone attribute of a POSIXct object, which would have solved my problem also. Denis Le 2011-06-05 ? 11:14, Spencer Graves a ?crit :
On 6/5/2011 9:30 AM, Jeff Newmiller wrote:
Sys.setenv(TZ="Etc/GMT+5")
Or:
x <- as.POSIXct(as.Date('2011-01-15'))
attr(x, 'tzone') <- "Etc/GMT+5"
x
This version works without Sys.setenv, which may not work on some platforms. Unfortunately, I believe there are some copy operations that lose attributes like tzone, so you need to check.
For some of the most advanced and complicated time series problems, you might consider what's available from the Rmetrics project, e.g., at "https://www.rmetrics.org/ebooks": They are designed to deal with coordinating trading data from financial markets all over the world, each of which affects all the others but have different trading hours.
Hope this helps.
Spencer
Make the timezone you prefer the default for that R session.
FWIW: EST may or may not exist as a valid timezone on your system, but it is an ambiguous notation anyway.
---------------------------------------------------------------------------
Jeff Newmiller The ..... ..... Go Live...
DCN:<jdnewmil at dcn.davis.ca.us> Basics: ##.#. ##.#. Live Go...
Live: OO#.. Dead: OO#.. Playing
Research Engineer (Solar/Batteries O.O#. #.O#. with
/Software/Embedded Controllers) .OO#. .OO#. rocks...1k
---------------------------------------------------------------------------
Sent from my phone. Please excuse my brevity.
Denis Chabot<chabot.denis at gmail.com> wrote:
Hi,
For a project I try to keep everything in normal time, not daylight saving time, to prevent problem when instruments collected data during the nights when we go from DST to normal time.
But sometimes R tricks me and I do not know how to prevent it.
This is one example:
lights_on = as.POSIXct(c("2011-05-06 04:09:26", "2011-05-07 04:07:53", "2011-05-08 04:06:21",
"2011-05-09 04:04:51", "2011-05-10 04:03:22", "2011-05-11 04:01:55",
"2011-05-12 04:00:30", "2011-05-13 03:59:06", "2011-05-14 03:57:45",
"2011-05-15 03:56:25", "2011-05-16 03:55:07"), tz="EST") # not DST
lights_off = as.POSIXct(c("2011-05-05 18:56:54", "2011-05-06 18:58:19", "2011-05-07 18:59:44",
"2011-05-08 19:01:08", "2011-05-09 19:02:32", "2011-05-10 19:03:55",
"2011-05-11 19:05:18", "2011-05-12 19:06:40", "2011-05-13 19:08:01",
"2011-05-14 19:09:22", "2011-05-15 19:10:42" ), tz="EST") # not DST
(a = lights_on[c(1,5)]) # not DST
[1] "2011-05-06 04:09:26 EST" "2011-05-10 04:03:22 EST"
(b = lights_off[c(2,6)]) # not DST
[1] "2011-05-06 18:58:19 EST" "2011-05-10 19:03:55 EST"
(x = c(lights_off[2], lights_on[2])) # suddenly DST
[1] "2011-05-06 19:58:19 EDT" "2011-05-07 05:07:53 EDT"
Why did x end up in DST? How could I prevent it?
Thanks in advance,
Denis
_____________________________________________ R-help at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. [[alternative HTML version deleted]] ______________________________________________ R-help at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
-- Spencer Graves, PE, PhD President and Chief Operating Officer Structure Inspection and Monitoring, Inc. 751 Emerson Ct. San Jos?, CA 95126 ph: 408-655-4567