DateTimePicker Problem -- One day behind

0
0

Hi,

There’s a problem with the DateTimePicker when selecting the date from the drop down calendar. The date that is selected is always one day behind. For example if you select April 1 the date put into the calendar text box will be March 31.

This behavior is not exhibited when run from the development environment.. only when we post to our website! Hopefully you will be able to reproduce.

We have narrowed down the version range when the bug first appears. Version 1.3.6 is working correctly but 1.3.8 (and up) is NOT working!

See the sample video attached.

Thanks,
Robin

 

  • You must to post comments
0
0

Hi Robin,

the fix for issue WJ-8208 is included in the latest Wisej development build (1.3.60).

Best regards
Frank

  • Robin Lao
    Confirmed fixed. Thanks!
  • You must to post comments
0
0

Hi Luca,

Thanks for the update!

Thanks,
Robin.

 

  • You must to post comments
1
0

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

 

  • You must to post comments
0
0

Looks like a time zone problem when parsing the date/time received from the client. Logged as WJ-8208.

Thanks!

/Luca

  • You must to post comments
Showing 4 results
Your Answer

Please first to submit.