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
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 NewmillerThe .
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
wrote:
> Is as.POSIXct1970{fda} useful here? That provides 1970-01-01 as the origin
> for as.POSIXct.
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 zon
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 (
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 a
On Fri, Aug 23, 2013 at 7:12 PM, David Winsemius wrote:
>
> On Aug 23, 2013, at 3:12 AM, Daniel Haugstvedt wrote:
>
> > I am replying to my own question in case someone else finds this tread
> and needs help with the same problem. Thanks to Mark Leeds for helping me
> on my way. Any errors or flaw
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
On Aug 23, 2013, at 3:12 AM, Daniel Haugstvedt wrote:
> I am replying to my own question in case someone else finds this tread and
> needs help with the same problem. Thanks to Mark Leeds for helping me on my
> way. Any errors or flaws are mine since I have rewritten most of his comments
> to
I am replying to my own question in case someone else finds this tread and
needs help with the same problem. Thanks to Mark Leeds for helping me on my
way. Any errors or flaws are mine since I have rewritten most of his comments
to make sure I understood them correctly.
First three general re
>From POSIXct to numeric and back with time zone
I am running regressions on data which has time series with different time
resolution. Some data has hourly resolution, while most has either daily or
weekly resolution. Aggregation is used to make the hourly data daily, while
liner interpolatio
11 matches
Mail list logo
