Thanks for those tips, Spencer. Will look at the code. That behavior is what I
would have expected in my naïveté .
--
David.
Sent from my iPhone
On Aug 25, 2013, at 7:56 AM, 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.
