Handling of times around daylight savings change

[tpetricek]

I suppose this will only reproduce when your computer is set to a timezone where the daylight savings time change happens on 30 March, but it should be easy to adapt:

(R.zoo([| 1.0 |], [| System.DateTime(2014,3,30).AddHours(0.0) |]) |> R.index).Print() 
// "2014-03-30 UTC"

(R.zoo([| 1.0 |], [| System.DateTime(2014,3,30).AddHours(1.0) |]) |> R.index).Print() 
// "2014-03-30 01:00:00 UTC"

(R.zoo([| 1.0 |], [| System.DateTime(2014,3,30).AddHours(2.0) |]) |> R.index).Print() 
// "2014-03-30 01:00:00 UTC"

(R.zoo([| 1.0 |], [| System.DateTime(2014,3,30).AddHours(3.0) |]) |> R.index).Print() 
// "2014-03-30 02:00:00 UTC"

The odd thing is that the second and third values print as the same time when they come back from R (possibly because at 1am, the UK clock jumps forward to 2am).

I have not investigated this further yet - so I'm not sure whether this is an issue with passing data into R or with getting data from R.

[jmp75]

Is the issue fixed or fixable in the RProvider, or is this an issue at the level of R.NET that you need to work around ? I'd be interested to know; incidentally I do not remember any date-time specific support in R.NET yet. Given the ubiquitous nature of time series, it probably should. Dealt with it for http://rclr.codeplex.com, so I am very aware of the many quirks of the topic...

[tpetricek]

There is some DateTime-specific code in the R provider here: https://github.com/BlueMountainCapital/FSharpRProvider/blob/master/src/RProvider/RInterop.fs#L123 So I suppose it might be R provider-specific? But I'm not sure..

[hmansell]

I think this is just dodgy behavior in DateTime. In the Eastern US, where the clock springs forward an hour at 02:00 on March 9th, I get similar behavior.

> DateTime(2014,3,9).AddHours(1.0).ToUniversalTime();;
val it : DateTime = 2014-03-09T06:00:00
> DateTime(2014,3,9).AddHours(2.0).ToUniversalTime();;
val it : DateTime = 2014-03-09T07:00:00
> DateTime(2014,3,9).AddHours(3.0).ToUniversalTime();;
val it : DateTime = 2014-03-09T07:00:00

It appears that DateTime computation results in invalid local times:

> DateTime(2014,3,9).AddHours(2.1);;
val it : DateTime = 2014-03-09T02:06:00

Microsoft's advice is to basically never use DateTime to represent dates with times. They developed DateTimeOffset to overcome the majority of the issues.

[tpetricek]

Yes, I suspect this might be the case. I'll try to change the tests and samples in Deedle to use DateTimeOffset.