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

[Jeff Newmiller]

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