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