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

[Spencer Graves]

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:<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.
>
> 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