Standardizing all month calls on getUTCMonth() did not help. Moving all to getMonth() did help, but introduced inconsistency with the rest of the code and timezone awareness in the code.
This commit moves back to an opaque "Date" object instead, so that the timezone handling logic is fully left to the JS engine. This has the nice upside of limiting the number of variables. The only special case is to force the day of month on the first day. Setting the first is arbitrary, but it is essential to set it to something lower than 28 to avoid issues in February.
As a bonus, this code fixes yearly data invalidation condition, where a year was compared with a month thus triggering a systematic invalidation.
There is a off by one error in the date picker. For example, when selecting "May" the actual selection becomes "April".
The date picker itself works fine as evidenced in the upstream playground https://v5.mui.com/x/react-date-pickers/date-picker/#views-playground.
Standardizing all month calls on
getUTCMonth()did not help. Moving all togetMonth()did help, but introduced inconsistency with the rest of the code and timezone awareness in the code.This commit moves back to an opaque "Date" object instead, so that the timezone handling logic is fully left to the JS engine. This has the nice upside of limiting the number of variables. The only special case is to force the day of month on the first day. Setting the first is arbitrary, but it is essential to set it to something lower than 28 to avoid issues in February.
As a bonus, this code fixes yearly data invalidation condition, where a year was compared with a month thus triggering a systematic invalidation.