Back to Questions
1.1k
views2
comments
System.DateTime Weirdness by Example
websharpersystem.datetime

So I decided to investigate the System.DateTime weirdness a bit.

Get the project here

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.

.

On further reveiw and playing around with the client side code, it appears that websharper is trying to do the right thing, but JS converts all times into local time. This is standard JS behavior. The weirdness appears to originate from the mismatch of .Net System.DateTime semantics and JS Date semantics.

I redact my advice. I am not sure what a best design decision should be with time. Maybe add a pointer to documentation about JS time with a blurb of gotcha's (Like Date("2015-03-01").GetMonth() will return 1 or 2 depending on what time zone you are in.

By on 12/27/2016 2:44 PM ()

Thank you very much for your detailed investigation!

I am working on a proxy for DateTimeOffset and enable it for remoting. In the first iteration, DateTime will remain to be supported only in UTC mode on the client, this limits the functionality of DateTimeOffset too, but those methods that will compile would be easier to use correctly.

By on 1/9/2017 2:12 AM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper