locked
Lightswitch decrements date. RRS feed

  • Question

  • For some reason, when our users select a date value using the LightSwitch HTML, the date value will get reduced by a day.

    The original value:

    Follow Up Date - Before

    I go to edit it...

    Follow Up Date - Edit Before

    I hit save. And then:

    Follow Up Date - After

    Request and response values are exactly what you'd expect:

    Request:

    Response Values:

    I have no idea what's going wrong. This is seriously messing with my client's ability to get their work done and ensure data is valid. I should also mention that refreshing the view shows the correct value.

    Thanks!

    Friday, March 7, 2014 8:15 PM

All replies

  • I recall that there was a bug in an earlier version. It was fixed and I can't remember which update/version that was in.

    Which version of Visual Studio and LightSwitch are you using.


    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.

    Saturday, March 8, 2014 6:14 PM
  • I'm currently using VS2013 with the LS RTM from that version. 
    jQuery-1.9.1, datajs-1.1.1, and msls-2.0.0.js.

    That being said, this was upgraded from a 2012 project and one thing I don't think I added was the nuget reference to the js runtime. I notice that there's an msls 2.5 available. Would that potentially solve my issue?
    Sunday, March 9, 2014 6:53 AM
  • You can see for yourself if you create a quick test app in VS2013, it should work ok. I cannot remember which script the problem was in and I only recall seeing it in a few prototype apps whilst waiting for an RTM release in VS2012.


    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.

    Sunday, March 9, 2014 1:22 PM
  • I plopped in msls-2.5.0.js and the bug appears to have persisted. One item I should note is that the date only decrements the first time one attempts to set it. 
    Monday, March 10, 2014 4:30 PM
  • I also started a brand new project of the development machine and it had the same exact behavior.
    Wednesday, March 19, 2014 5:43 AM
  • Hi Richi,

    A few quick snippets. Is this an intrinsic or external data source? You appear to be using date not datetime which I initially missed so what you are seeing could be 'expected behaviour'. Perhaps the field in question should be 'Date Time Offset' so that timezones work correctly?

    Can you let us know the time-zones of the client and server environments involved, thanks.

    Dave


    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.


    • Edited by Xpert360 Wednesday, March 19, 2014 10:28 AM
    Wednesday, March 19, 2014 10:18 AM
  • Intrinsic for the test project, external for the client project. Both exhibit the same behavior. Every date in question does infact use Date. That doesn't explain why when you first load the page and when you change and save a date it's displayed correctly.

    All the enviroments I'm working in are GMT -5.

    Richard

    Wednesday, March 19, 2014 10:34 AM
  • It still could be a 'bug' but the workings is getting clearer. You can see that a date and time is passed around, if that is interpreted as UTC and then displayed and adjust for GMT -5 it will appear to decrement the date. Just wanted to check also whether this was Win Azure/SQL (al run UTC) or local or a server deployed somewhere.

    If it was external SQL and a short date it would have no time part. As there is no 'Date Offset' business type but only 'Date Time Offset' this is an interesting situation. I'm just running a few extra checks.


    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.

    Wednesday, March 19, 2014 10:42 AM
  • This shows a 'Date' business type field in an intrinsic database as 'datetime'. Note the 'datetimeoffset' tracking fields.


    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.

    Wednesday, March 19, 2014 12:56 PM
  • I should mention that the SQL data types of the offending fields are literally just "Date" in the external database scenario. I thought localization too, but that doesn't explain why it only happens on first save and not when the date is freshly loaded.
    Wednesday, March 19, 2014 1:03 PM
  • Well it is localization/time-zone but perhaps LightSwitch libraries should be ignoring or discarding the time element. I can reproduce it here in debug and it goes:

    First time:

    Enter 2012-11-27 ("2012-11-27T00:00:00")

    Redisplays as "2012-11-26" from dataworkspace cache

    Stored in database as '2012-11-27 00:00:00"

    Close the app, re-run it now shows as "2012-11-27"!

    If you immediately re-edit the data and change it again to 2012-11-27 (it is "2012-11-27T19:00:00")!

    Stored in database now with the time.

    When you deploy it I suspect (as you say it is just 'Date') the LightSwitch dataworkspace cache behaves as above but as the database does not store time it starts always with 'T00:00:00' when the service layer re-reads it.

    And the solution is...


    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.

    Wednesday, March 19, 2014 3:28 PM
  • Try this out but it really needs testing to destruction if users are in multiple time-zones. I tried it with GMT -5 and +9 but it is tedious switching and I have only tested in debug...

    function toODataJSONFormat(data, type) {
    
    ...
    
                case ":DateTime":
                case ":DateTime?":
                    data = new Date(data.valueOf());
                    data.setMinutes(data.getMinutes() - data.getTimezoneOffset());
                    return data;
                case ":Date":
                case ":Date?":
                    data = new Date(data.valueOf());
                    return data;
    
    ...

    It is a hack but one that you may be able to live with for a while. Let us call it a work in progress and hope for some more feedback. The code is not good but the missing line makes it obvious what is happening here.

    Dave


    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.


    • Edited by Xpert360 Wednesday, March 19, 2014 5:43 PM
    Wednesday, March 19, 2014 5:42 PM
  • Here is a non-msls hack-around that seems to work but certain would need testing to destruction too:

    myapp.AddEdit{your-screen}.beforeApplyChanges = function (screen) {
        var dte = screen.{your-entity-prop}.{your-date};
        if (dte.getHours() == 0)
            dte.setUTCMinutes(dte.getTimezoneOffset());
    };
    

    I am not 100% happy with either hack pending some more time-zone testing. This hack is once per date field. Users in multiple time-zones, last one wins.


    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.

    Wednesday, March 19, 2014 6:21 PM
  • The real answer here is that Date is sent over OData as DateTime, and since it doesn't have an offset it's interpreted as UTC. Javascript then interprets it as a local date and automagically applies the timezone offset. What I think I'm going to do instead is in parseDateTimeMaybeOffset in datajs, I'm going to add a check for T00:00 and apply the timezone offset to the UTCMinutes there.
    Wednesday, March 19, 2014 7:35 PM
  • If that were the whole story. Don't forget that the LS cached value differs from that when you force a data refresh by closing/opening the app. It gives me a headache just thinking about it. If there was a true date implemented life would be simple. DateTimeOffset works but you need to roll your own date picker and custom render everywhere...

    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.


    • Edited by Xpert360 Wednesday, March 19, 2014 8:01 PM
    Wednesday, March 19, 2014 8:00 PM
  • I've put it through testing and it appears to be quite happy. For whatever reason, the only time LS misinterpreted date was when it got a batch change back through OData after a save request. Keeping an eye out for anywhere else it might be flawed, but that seems to have done it.
    Wednesday, March 19, 2014 8:04 PM
  • From what you say that fix is like the second hack. We may have to raise a connect bug to get it fixed unless a team member picks up this thread. I will still get to give it a good work out here sometime in the next week. Seat-of-the-pants stuff heh? Cheers Dave

    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.

    Wednesday, March 19, 2014 8:30 PM