Is as.POSIXct1970{fda} useful here? That provides 1970-01-01 as the
origin for as.POSIXct.numeric. Spencer
p.s. as.Date1970{Ecdat} does the same for as.Date.numeric.
On 8/25/2013 7:35 AM, Jeff Newmiller wrote:
If the data you are reading contains timestamp information from multiple time zones in
one field, then each time value needs to specify its own time offset. In most cases I
encounter, each data set corresponds to it's own time zone. For importing the latter,
using Sys.setenv() with a supported (zoneinfo) time zone specification string appropriate
to that data just before converting from string to POSIXct is the least painful option I
have found. If the input data you typically work with is represented with both standard
and daylight time, then yes, I would agree that using "America/Los_Angeles"
would be best. That representation does have ambiguity in the autumn time shift from
daylight to standard that can only be resolved cleanly by including and parsing the
offset in the time string itself, but if you don't expect to encounter timestamps in that
one hour interval then you can neglect the offset if your TZ is set.
---------------------------------------------------------------------------
Jeff Newmiller The ..... ..... Go Live...
DCN:<jdnew...@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.
David Winsemius <dwinsem...@comcast.net> wrote:
On Aug 23, 2013, at 1:22 PM, Jeff Newmiller wrote:
I disagree with the characterization that setting TZ to anything but
UTC yields confusing results. If your time strings do not specify a
time offset, then TZ will be assumed, and if the assumed time zone
accounts for daylight savings and you don't want it to then you might
be disappointed in the results. I work mostly with standard time year
round so I often use the Etc/GMT+8 or similar zones when converting
time strings. I have not figured out why as.POSIXct accepts a tz
argument... only as.POSIXlt seems to pay attention to it.
I pointed out that in the case of a first argument being character or
factor that as.POSIXct.default passes its arguments to `as.POSIXlt'
(for which there are a battery of methods as well. If the argument was
numeric that processing did not occur, and I see no checks on the
validating of the tz argument when as.POSIXct.numeric is called.
You might want to read
https://stat.ethz.ch/pipermail/r-help/2013-August/357939.html for some
related discussion.
So your advice to me would be to use
Set.sysenv(TZ="America/Los_Angeles") and to use a +/-NN00 format for
processing character data?
______________________________________________
R-help@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 Technology Officer
Structure Inspection and Monitoring, Inc.
751 Emerson Ct.
San José, CA 95126
ph: 408-655-4567
web: www.structuremonitoring.com
______________________________________________
R-help@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.
