[R] From POSIXct to numeric and back with time zone

[David Winsemius]

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.graves at 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:<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.
>> 
>> David Winsemius <dwinsemius at 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 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 Technology Officer
> Structure Inspection and Monitoring, Inc.
> 751 Emerson Ct.
> San José, CA 95126
> ph:  408-655-4567
> web:  www.structuremonitoring.com
> 
>