So I decided to investigate the System.DateTime weirdness a bit.
I have not started to poke around the source code of websharper; this is testing that treats websharper as a black box.
It appears that on the server side all DateTimes are converted to UTC time before being transformed into a number, which I think is milliseconds from epochUTC.
Okay so good, we are translating server DateTimes into "ms from unix epoch".
Now the weirdness happens on the client side. Since there is no System.DateTimeKind value passed to the client, all times are converted to local time. This has the weird effect that sending local unix epoch works but sending UTC unix epoch (the real unix epoch) will put you on a different date in the westener hemisphere.
Now we test remoting.
When DateTimes are passed back as parameters, their DateTimeKind is reported as UTC and is the date is actually UTC time. I think everything is probably converted back to UTC and sent.
This is a issue. Client receives times as UTC and converts to local time. Server receives time as UTC and converts to UTC. Other weirdness can happen due to DateTime not checking DateTimeKind when doing time comparisons and differences. see DateTime source. This means that the weirdness it probably due to no one understanding what is going on when System.DateTime types are passed from client to server and server to client, and no one understanding that (x-y) when x is UTC and y is local results in TimeSpan(x.Ticks - y.Ticks) because it is only recently that we get to browse the source code from MSDN.
I would advise that client time is interpreted as UTC to avoid confusion.