> You might do better using seq.POSIXt. Your basic problem is that your > sequence includes a time that doesn't exist, 02:00 on the transition > day.
Thanks. I guess I didn't state my question clearly enough. I didn't use seq.POSIXt because I was interested in reading times not necessarily in a regular sequence. seq.POSIXt does give the even time series, as you showed, and it includes the 02:00 GMT time on 4 April. I chose GMT because I thought 02:00 should exist in that time zone. My question could be rephrased to be why do seq.POSIXt and ISOdatetime differ between 02:00 and 02:59:59, or at least why do they differ in Linux and Windows, since they don't in OS X. > diff(ISOdatetime(2004,4,4,0:5,0,0,"GMT")) Time differences of 3600, 7200, 0, 3600, 3600 secs > diff(seq.POSIXt(ISOdatetime(2004,4,4,0,0,0,"GMT"),length.out=6,by="hour")) Time differences of 1, 1, 1, 1, 1 hours Shouldn't these be the same? They are the same on R in OS X > Whatever the timezone, if the change from standard time to daylight > savings time takes place at 02:00, then there are no "times between > 2:00 and 3:00". That is, the correct sequence of times is 01:58, > 01:59, 03:00, 03:01, etc., because at 2 AM we jump directly to 3 AM > (that's what daylight savings time is, after all). > > seq.POSIXt(ISOdatetime(2004,4,4,1,58,0),by='min',len=5) > [1] "2004-04-04 01:58:00 PST" "2004-04-04 01:59:00 PST" "2004-04-04 > 03:00:00 PDT" "2004-04-04 03:01:00 PDT" "2004-04-04 03:02:00 PDT" > > When I first encountered this issue a while back, the advice was that > if you specify times that don't exist (such as 02:00 on the > transition day), what happens depends on your OS; and one should not > expect it to make sense because in fact the time doesn't exist. That is why I chose to use GMT in my example, because in addition to being the only time zone string I noticed in the R documentation, it shouldn't switch to daylight savings time and should have the hour between 2:00 and 3:00. > A final note, in my OS X system, I get > > > ISOdatetime(2004,4,4,0:4,0,0) > [1] "2004-04-04 00:00:00 PST" "2004-04-04 01:00:00 PST" NA > "2004-04-04 03:00:00 PDT" "2004-04-04 04:00:00 PDT" > > I would consider this correct, since it gives NA for > ISOdatetime(2004,4,4,2,0,0), a time that doesn't exist. Excluding the > NA, it results in one hour intervals. I'd consider that correct too because it assumes you are entering times from your local time zone which varies between PST and PDT and has no 02:00 time when switching to DST. I played a bit more with OS X I found I can get three distinct results depending on the time zone I enter. Besides your example: for "GMT" (I get the same result with "PST8" or "EST5"): > ISOdatetime(2004,4,4,0:4,0,0,"GMT") [1] "2004-04-04 00:00:00 GMT" "2004-04-04 01:00:00 GMT" "2004-04-04 02:00:00 GMT" "2004-04-04 03:00:00 GMT" "2004-04-04 04:00:00 GMT" for "PST5", or apparently any timezone string the OS does not recognize: > ISOdatetime(2004,4,4,0:4,0,0,"PST5") [1] "2004-04-04 00:00:00 EST" "2004-04-04 01:00:00 EST" "2004-04-04 02:00:00 EST" NA NA All of these make some sort of sense. If I enter a specific time zone such as "GMT" it should assume all the times are from that time zone, even if the place those times were recorded changes from standard time to daylight savings time. For the last example above, if I enter an unknown time zone, then it doesn't know what to do when daylight savings time would start. (As an aside, So, to add to my question above, how can I get R in Linux (or Windows for that matter) to behave like OS X in this matter? Thanks again Ian Kennedy ______________________________________________ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
