DateTimePicker Problem -- One day behind

Hello Robin,

To keep you updated, the issue is that the server (any server running any web framework) can only have 1 time zone. Windows and .NET only allow for one system-wide time zone. It’s different from the localization information which can be changed for each thread. Therefore, Wisej can sync the locale of the thread responding to a request with the client, but it’s impossible to sync the time zone.

The issue you found (thank you!) with the DatePicker is the formatting of the text. Wisej handles (serialize and parse) the date/time correctly since it communicates with the client always using UTC dates, which then the client converts to valid javascript dates according to the timezone of the browser.

But… the DateTime picker also formats the date into text and send back to the widget also the text to show since we support custom formatting and .NET formattig which is very different from javascript formatting. When the server formats the date it necessarily uses the timezone of the server, resulting in the wrong text being display when the timezone doesn’t match, as in your case.

The fix for the DateTmie widget is to convert the date to the client’s time zone before formatting, which is simple since we have the client’s time zone offset in Application.Browser.TimezoneOffset.

However, we can’t override the DateTime.ToString() so developers have to be aware that the timezone on the server may not match the timezone of the client when formatting a DateTime to a string. DateTime structures in .NET do not carry the time zone information, therefore date operations are not affected. Only formatting is.

We have added a number of extension methods to DateTime that will help, instead of ToString() now in Wisej you can use Format: myDate.Format() and it will always format using the client’s time zone. We have have myDate.ToClientTime() and Application.ToClientTime(DateTime).

Will be in the next update.

Best,

Luca