Repository navigation
datepicker: min-date validation bug #11963
Description
Activity
- changed the title
[-]datepicker min-date validation bug[/-][+]datepicker: min-date validation bug[/+]on Jul 17, 2020 I am not able to reproduce this in a GMT-4 time zone at 6:30pm EDT.
I could try changing my computer's time zone in order to test this, but I need to know what the local time is for you when you are able to reproduce this?
Oh and for step 4, is that really two steps combined? I.e. select some other valid date, then reselect the min date again?
The datepicker is malfunctioning on our personal app when local time is at midnight GMT+4.
On the angularJs demo page, at different times of the day (At 8:50am GMT+4 for example).
For step 4, you need to select the min date twice in a row. First time it's valid, and second time it's not.you need to select the min date twice in a row
This is what I'm not clear on. Are these the steps for this step 4?
4a. Select another date
4b. Select the min date againHowever, I may be getting this wrong as it doesn't satisfy the "twice in a row" part of your description.
No I mean twice in a row as in :
- I first select the min-date
- I reopen the calendar
- I reselect the min-date (even though it's already selected)
This is on the demo page.
On our app, the datepicker is invalid at the init of the page. Local time is at midnight GMT+4. In the method DateUtil.removeLocalTzAndReparseDate, value.getTimezoneOffset() equals -240, so
dateValue = new Date(value.getTime() + 60000 * value.getTimezoneOffset());
decrements our date, which is then inferior to the min-date.Reacted by Michael PrenticeOK, that helps a lot thank you! I wasn't sure that I was doing it right, since I can't reproduce it.
I think that we're going to have to change the calculation for all
GMT+Xtimezones.Reacted by vdury6 remaining items
I don't understand the purpose of
removeLocalTzAndReparseDate. I found an interesting page about converting dates to UTC here, if this was the goal:
https://praveenlobo.com/blog/how-to-convert-javascript-local-date-to-utc-and-utc-to-local-date/Reacted by Michael PrenticeHi, I looked deeper into the code and found that the problem we have is located in the method
DatePickerCtrl.prototype.onExternalChange.Thank you very much for looking into this.
I guess that I didn't explicitly state it above, but my previous investigation did identify that the approach used via
removeLocalTzAndReparseDate()only works for GMT-X timezones and not for GMT+X timezones.I am not sure if this doesn't break the
allow specifying timezonefeature.The effect of this can be seen locally using the datepicker's Ng Model Options Timezone demo which uses
ng-model-options="{timezone: 'UTC'}".
These examples below are given using a local timezone that is GMT-4:00.With the existing code:
The date is properly set to midnight 6/19 in the UTC timezone for both the calendar and datepicker.With
removeLocalTzAndReparseDateremoved fromDatePickerCtrl.prototype.onExternalChange:
The date is properly set to midnight 6/19 in the UTC timezone for the calendar.
The datepicker dates are both 20 hours earlier than they should be in both timezones.So yes, this breaks the support for specifying
ng-model-options="{timezone: 'UTC'}"with UTC or another timezone when in a local GMT-X timezone.Now when testing locally with a GMT+3:00 timezone:
With the existing code:
The date is properly set to midnight 6/19 in the UTC timezone for both the calendar and datepicker.With
removeLocalTzAndReparseDateremoved fromDatePickerCtrl.prototype.onExternalChange:
The date is properly set to midnight 6/19 in the UTC timezone for the calendar.
The datepicker dates are both 3 hours earlier than they should be in both timezones.It appears that I can fix this by not doing the
removeLocalTzAndReparseDate()call ifng-model-optionsisn't specified with a timezone setting:if (this.dateUtil.isValidDate(value) && timezone != null) { this.date = this.dateUtil.removeLocalTzAndReparseDate(value); } else { this.date = value; }
That however, does not fix an issue where the stand-alone calendar and calender in a datepicker, when a date is clicked on (in a GMT+X timezone when using
ng-model-options="{timezone: 'UTC'}"), selects the previous date:In this case, 6/19 is manually clicked upon in the stand-alone calendar and calender in the datepicker:
In a GMT-X timezone, this works fine:
But that appears to be a separate problem from this one, so I'll open a new issue.
Update: #12000 opened for this issue.
- linked a pull request that will close this issuefix(datepicker): min-date validation is incorrect in GMT+X timezones #12002
on Aug 28, 2020 - added a commit that references this issue
on Aug 31, 2020 - added a commit that references this issue
on Aug 31, 2020
Bug
In angular material 1.1.24, the datepicker directive sometimes invalidates a date if md-min-date is equal to selected date.
Demo and steps to reproduce the issue
Demo URL : https://material.angularjs.org/1.1.24/demo/datepicker#validations (Validations)
Detailed Reproduction Steps
Explain the expected behavior
md-min-date is supposed to be inclusive, so we expect 16/05/2020 to be always valid on 16/07/2020.
List the affected versions of AngularJS, Material, OS, and browsers
Add anything else we should know
We suspect method DateUtil.removeLocalTzAndReparseDate (introduced in commit) to be at the origin of the problem.