Input Date Issue

Posted by: tfoster on 2 July 2019, 3:14 pm EST

  • Posted 2 July 2019, 3:14 pm EST

    We’ve been dealing with an issue in the ‘wj-input-date’ control for quite some time, but have struggled to put together an actual example, until now: http://jsfiddle.net/f40kbvou/. This fiddle demonstrates a very strange situation where when the property being bound to control is initialized to ‘Today’, you cannot type a new date value into the control using the keyboard (you’re only allowed to drop-down and select a new date). However, if the property is initialized as any other date, it works as expected. Unfortunately, the way our application is architected, this actually happens quite a bit and affects quite a few of our customers. Please let us know when a fix for this might be available and whether there may be a viable workaround in the meantime.

    Thanks!

    Terry Foster

  • Posted 3 July 2019, 9:24 am EST

    Hello Terry,

    We are sorry for the inconvenience, we are continuing our investigation. We will update you as we get further update on this

    Also, could you please share with us what behavior you are trying to achieve using the defineUtcDateProperty method?

    Please try using the toUTCString method to convert the date to UTC as demonstrated in the sample below:

    http://jsfiddle.net/859euaqd/

    Regards,

    Manish Gupta

  • Posted 3 July 2019, 10:17 am EST

    Thanks for the response so far. Yes, it’s kind of hard to explain, but for some Date-based fields on some of our DTOs, we need to maintain two different versions of the date value (but that are linked) - one that keeps the original time zone offset forced by the browser, and one that appears to be time zone agnostic that the user can manipulate through the Input Date control. Ultimately, we’re just trying to allow the user to select a certain day that is not tied to any time zone, that looks the same on the server as it does on the browser for all users, regardless of their time zone, which has proven to be annoyingly difficult.

  • Posted 4 July 2019, 9:22 am EST

    Hello,

    To store 2 different types of date, you may use the valueChanged event of InputDate and convert the InputDate’s value to UTC using the toUTCString method. Please refer to the sample below:

    https://jsfiddle.net/6cjun91x/

    Regards,

    Manish Gupta

  • Posted 5 July 2019, 8:26 am EST

    Thank you - we will take this under advisement. Unfortunately, we have a lot of areas in our application that are making use of the input-date control in this manner and we would prefer to not have to hook up an extra event for each instance, nor remember to have to do this for any new instances. Besides, our current system works well in all cases except when the date starts out as ‘today’. Do you think you’ll be able to come up with a fix for this strange issue?

  • Posted 8 July 2019, 7:27 am EST

    In the sample provided, today’s date is being passed as a string. Could you please try to pass the date using the Date() constructor of Javascript and let me know if it works for you.

    Sample: http://jsfiddle.net/hj76q90m/

    Also, we are still investigating this issue. We will give you an update as soon we have further information

  • Posted 8 July 2019, 10:16 am EST

    You’re right - when constructed without using the string, it appears to work correctly, at least initially. Unfortunately, in our application, there are still situations where it stops working, apparently due to the life cycle of our Date values as they are saved or canceled through modal windows. Still quite strange and inexplicable. Yes, please keep us updated on your progress in resolving this issue.

  • Posted 9 July 2019, 7:15 am EST

    Could you please tell us more about the situation where the Date() constructor does not work or maybe you could provide us with a sample where the above solution does not work so we can investigate further?

  • Posted 10 July 2019, 2:38 pm EST

    When displaying one our data objects in a custom modal editor window, we start an editing transaction, which copies all properties to a new ‘snapshot’ of the data object. Then if the user clicks ‘Cancel’ on the edit modal, we restore all properties from the snapshot back to the data object being edited. Then when launching the edit modal for the data object again, input-date keyboard editing no longer works. Unfortunately, I’m not able to provide a sample of this.

  • Posted 11 July 2019, 7:23 am EST

    Hi again,

    We tried to replicate the situation in which the above solution does not work but we were not able to replicate the issue. Please refer to the sample provided and let us know if we are missing something or you may also modify the sample to replicate the issue.

    http://jsfiddle.net/2sg6ey5h/

  • Posted 15 July 2019, 10:07 am EST

    I tried, but unfortunately I could not seem to replicate the same situation that we have in our production environment.

    Ultimately, it’s kind of moot, though. You can still replicate the issue by simply initializing the Date property with a string for ‘today’ (“2019-07-15T00:00:00Z”). I suspect that if you can fix the control for this case, it should fix it for the other cases. Any progress on this yet?

    Thanks.

  • Posted 16 July 2019, 3:25 am EST

    We have added an enhancement request with internal tracking id 390219 to add a property which will give the UTC date in the InputControl. Until this feature is implemented, I would recommend you to use the valueChanged event to get the UTC date as a workaround which we provided earlier.

  • Posted 17 July 2019, 11:49 am EST

    While a new property that allows binding to a time-zone-agnostic date could prove quite useful, I can’t help but feel that you guys are skirting the main issue here. Why should the control behave any differently when binding to a Date instance with no constructor parameter vs. one with a ‘today’ string parameter? Can you at least tell me whether you plan to address this specific issue at all so we can plan accordingly?

    Thanks.

  • Posted 18 July 2019, 9:32 am EST

    Hi,

    We are sorry for the inconvenience. We have also queried the dev team on why this issue is arising. We will give you an update as soon as we hear something from them.

  • Posted 21 August 2019, 7:54 am EST

    Hi Terry,

    The issue has been fixed in the latest nightly build of wijmo. You may verify the same using the sample below:

    https://stackblitz.com/edit/angularjs-s2jxm7

    PS: The nightly builds have not passed through the QA cycle as all of our release builds do and therefore are not suitable in the production environment.

    ~regards

  • Posted 7 October 2019, 1:09 pm EST

    Hi Ashwin,

    Do you have an estimate on when this fix / nightly build will pass through the QA cycle?

    Thanks,

    Paul

  • Posted 8 October 2019, 11:45 pm EST

    Hi Paul,

    This issue has been fixed in the latest release build (5.20192.631). You may verify the same using the link below:

    http://jsfiddle.net/cp40waxs/

    ~regards

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels