You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 28, 2019. It is now read-only.
// Update the date picker when the model changescontroller.$render=function(){vardate=controller.$viewValue;if(angular.isDefined(date)&&date!==null&&!angular.isDate(date)){thrownewError('ng-Model value must be a Date object - currently it is a '+typeofdate+' - use ui-date-format to convert it from a string');}element.datepicker("setDate",date);};
Apologies to start off with a code block. I've read that this part is intentionally strict in what it accepts (Date objects, null or undefined). However, when you define a ng-model, e.g. on an input, it defaults to empty string (""). In this case one has to define the value explicitly to null or undefined (in controller or via ng-init), otherwise it will throw the exception. Wouldn't it be reasonable to be more forgiving and treat emtpy strings like nulls in this place?
The text was updated successfully, but these errors were encountered:
I think I'm having a similar issue... my initial ng-model value is not shown in the text field, I fear because it comes back from my server in the form: 2015-01-09 12:00:00 AM
@JaKXz ui-date doesn't currently handle multiple formats that well unless custom parsers are defined. If it is really coming from the server in a different format, for now the easiest way would be to convert it to the date format you are expecting before using it.
Apologies to start off with a code block. I've read that this part is intentionally strict in what it accepts (Date objects, null or undefined). However, when you define a ng-model, e.g. on an input, it defaults to empty string (""). In this case one has to define the value explicitly to null or undefined (in controller or via ng-init), otherwise it will throw the exception. Wouldn't it be reasonable to be more forgiving and treat emtpy strings like nulls in this place?
The text was updated successfully, but these errors were encountered: