coreui / coreui-pro / 36351653786

96%

main: 94%

push

github

fix(Calendar): keep years below 100 in every date the calendar builds (#1455)

The Date constructor reads a year below 100 as 1900 plus that year, and
the Date parser reads the toDateString form of one, such as
"Thu Dec 31 0099", as 1999. The calendar built its cells, its second
panel and its key targets with the constructor and read the date of a
cell back with the parser, so a page of year 99 drew 1999 under the
heading of year 99, its next panel was January 2000, and an arrow key
from its last day jumped to 2000.

Every date built from a year now goes through createDate, which sets the
year with setFullYear as the page change already did, and the date of a
cell is read back with parseToDateString, which reads the toDateString
form itself and gives an invalid date for any other string. Both are
exported from util/calendar, and the React and Vue calendars build
their period cells with createDate. The parsers, the ISO week helpers
and getDateFromSections use it as well, although no year below 100
reaches them yet: parseYearSmart still turns every such year into one
within fifty years of today.

Once a page can reach year 0 and earlier, those years are out of reach
the way dates before minDate are: isDateDisabled and isPeriodDisabled
treat anything before 1 January of year 1 as disabled, and the arrow
keys and Page Up stop there. The formatter prints no era, so the
keyboard would otherwise move from year 1 to a year 0 also named 1. A
date field now reports year 0000 as disabledDate while it is typed; the
year section still clamps it to 1 on blur.

The change adds 387-443 B gzip to the unminified bundles and 122-136 B
to the minified ones against v6-dev, measured with gzip-size as
bundlewatch does. Under the old ceilings coreui.bundle.js, coreui.esm.js
and coreui.js would be 426, 343 and 217 B over and coreui.bundle.min.js
and coreui.esm.min.js 47 and 13 B over, so the first three get 0.5 kB
more and the other two 0.25 kB.

6196 of 6756 branches covered (91.71%)

Branch coverage included in aggregate %.

49 of 49 new or added lines in 3 files covered. (100.0%)

11248 of 11568 relevant lines covered (97.23%)

851.12 hits per line