On 8/25/2013 8:42 AM, Jeff Newmiller wrote:
That is only useful when converting numeric seconds to POSIXct, which I avoid
doing if at all possible. This discussion is about converting datetime strings
to POSIXct.
Thanks. Please excuse me for jumping in the middle without
reading the entire thread. Spencer
---------------------------------------------------------------------------
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.
Spencer Graves <spencer.gra...@structuremonitoring.com> wrote:
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.
