There is a date constellation for which the datetimepicker returns null. This example is based on your documentation and just enhanced to show the effect:
It allows you to choose a date only equal or bigger than 1th of January 2018. That is working fine choosing from datetimepicker. Now proceed with this:
1. Use/start code above
2. Open Browser console
3. Chose date 1th of January 2018 from datetimepicker (it will be set in the input field, fine)
=> You will see the proper date/time in the console
4. Click into input field of datetimepicker and change the year to 2017
5. Click key 'Tab' to leave the input field to make the change trigger fire
=> You will see 'null' in the console!
It looks like the datetimepicker can't handle manually changed date/time in the input field lower than the set min(date).
In such a case I would expect the datetimepicker Widget would set back a previously set (valid) date or at least returning the set date even if it's lower than the min date. As a programmer I can't work with 'null' in such a case (it also could mean the date was deleted manually). Of course I could previously store any set date and in case of 'null' set that one back but I think this is not the idea. I also made a check with the 'max' option that ended up with the same behaviour.
8 Answers, 1 is accepted
I can confirm that this is the default behavior of the widget.
Still, if the Dateinput option is used, the widget should automatically show the min value, but its currently only visually setting the min value and the actual one is still null:
As this is not expected I created an issue in our GitHub repository and forwarded it to our developers for fixing. You can track its progress at:
For a workaround, I can suggest checking the value during the change event and if it is null to programmatically set it to the min value:
Additionally, I updated your Telerik points for bringing this to our attention.
Excellent answer, thank you!
In fact I'm using the Dateinput option and it behaves as you described. It shows the min date in the input field but in background it returns null in the change event. So that confused me initially and it took me a while to find this "bug".
In my case I have two datetime input Widgets, start and end (of an event). The "end" can be empty (= open end). Your workaround example is not working in my case because if the user empties the "end" input of the datetime Widget manually then it returns null as well. So I can't differ programmatically between the user emptied the end datetime input OR the set date/time is lower than the allowed min value. This should be considered when fixing the bug.
So I probably have to store previously the datetime value (if set) before any change happens to be able to differ before and after any change happens.
No big thing but just to mention it: Your emails I receive after you added an answer in the forum here first show your personal image in a huge way and right of your image (scrolling right) the text content appears (see attached email.png). I'm working on Mac and maybe this problem exists only on Macs email client.
I'm glad to hear that the answer was helpful.
In the described case when there are min and max dates indeed an additional logic has to be used to ensure that the dates are set correctly. We have a demo demonstrating a similar approach. Its implementation will not completely cover the case, but it could be used as a start:
As for the email and the picture, thank you for sharing this with us I will forward it to the team responsible for the ticket system.
I have switched to the latest Kendo UI Professional v2018.1.221. If I see that right then the correction is done this way: If there is a date set in the KendoUIDateTimePicker that is out of min/max range of the picker it will be set to the min date if the user opens the dropdownlist (date or time) and aborts it (pressing ESC or clicking anywhere else outside the Picker).
The mentioned bug at Github was just closed and that solution doesn't help in my project:
There is a start date and an end date (both DateTimePicker). The start date must be 3 days in the future from now (systime). The end date is dynamically set to start date + 1 minute. So when the user sets a start/end date and returns some days later when the set dates are out of min range he has to set them again (again with a date in the future). Now when the user opens the start date picker and doesn't change anything (aborts it as mentioned above) the min date/time will be set for that dateTimePicker. That would be ok if I could also react on that programmatically but all related events do not fire and therefore not giving me the option to reset the end date timepicker as well!
Furthermore I have a list in the background to tell the user what is wrong. The startdate is also part of that list telling the user he has to re-set the start/enddate. In the described case and with no events I can't refresh the list in the background on aborted dateTimePicker choice. The list tells the user the startdate is still out of range while the aborted choice automatically set the date to the min range - confusing for the user.
So I still don't know how to handle that. Hope you can help me!
We examined different options for the issue that is linked by Stefan in a previous post. However, any of the available changes we can make would cause a breaking change in either the DatePicker or in the DateInput component.
What would probably be the least breaking change is to clear the date when it is out of the valid scope. What do you think of such behavior? Will it work for your scenario?
With that said I would suggest adding validation to ensure that the date entered by the user is valid. Check out the Validator example example below that illustrates how it can be integrated with various components.
I just have checked your Dojo example at http://dojo.telerik.com/oPuKIxez/3
So if I understand it correct the widget will still set the min date (when out of range) and new: set the min date too as value of the datetimepicker (instead of keeping it to null). This would work for my project. I then could get the current set date in the close event of the widget by knowing there is always a valid returned date in the datetimepicker.value() that I can work with in the background.
Would this change take effect with the next KendoUI release?
Your understanding is correct - when the DateInput corrects the value it is applied to the picker component so it does not return null.
With that said, adding such code internally in the components would introduce a breaking change in the DateInput and also the Date(Time)Picker. Furthermore such logic would mean that the DateInput "knows" about its wrapper and this is considered bad practice.
I'm sorry, I missunderstood you this time. I thought this is also a solution you want to implement. I'm fine you don't since it's a rule breaker. I now implemented this workaround in my project and it's working great! Thanks a lot for your help!