[R] Entering times around the start of daylight savings time

[Ian Kennedy]

> 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