Kendo-angular: [DateInput/Picker]: Support typing 2 digit year

[JaapMosselman]

I'm submitting a...

• Suggestion for improvement

Current behavior

Typing "6718" results in 6/7/0018.

Expected behavior

Typing "6718" results in 6/7/2018. "6770" results in 6/7/1970. "6760" results in 6/7/2060.
The 2 digit year should be expanded when the year segment is left (e.g. by moving to other segment or on blur).
Use the following rules: prefix the 2 digits with the current century. If that new year is more than 50 year away from current year, than add or substract 100, depending on if that new year is before or after current year.
let diffYears = newYear - currentYear;
if (Math.abs(diffYears) > 50) {
newYear += diffYears > 0 ? -100 : 100;
}
Or should years in the past have a higher preference?

The need for the years 0001-0099 is very unusual and can still be created by just typing the four digits.

Minimal reproduction of the problem with instructions

Goto https://www.telerik.com/kendo-angular-ui/components/dateinputs/datepicker/
clear the field
type 6718

[bahman616]

That is a good suggestion! Also, min and max property can be used for enhancing the user input. Suppose I set min to 1/1/2000 and max to 1/1/2100. When I enter 6718 I expect the date to be set to 6/7/2018.

[dtopalov]

Also requested in Ticket ID: 1345357

[zhaparoff]

This one is a real headache, making date formats with 2-digit code like "dd/MMM/yy" unusable without workarounds.
As for me, I'm using IntlService for this:

// brokenDate = 23-10-0018
const dateFormat = "dd/MMM/yy";
const txtDate = this.intlService.formatDate(brokenDate, dateFormat);
const normalizedDate = this.intlService.parseDate(txtDate, dateFormat);
// normalizedDate = 23-10-2018

This code properly parses date in my case (for 2000-2020)

I'm wondering why Kendo doesn't use it's own localization service inside the component to handle this?

[dtopalov]

Also requested in Ticket ID: 1365347

A possible temporary workaround is to handle the valueChange event, and create the desired new date when the incoming date's year segment is less than 100:

https://stackblitz.com/edit/angular-1pfghr?file=app/app.component.ts

[PeterStaev]

This is a really important feature as people are used to type 2 digit years. The suggested workaround above does not work correctly. For example type 19 and the year changes successfully to 2019, but then enter 18, you would assume the year to be 2018, but instead it turns to 819.

[zhaparoff]

@PeterStaev,

Probably, some delay should be added before processing, so normalization won't be triggered for each typed digit of the same year. I'm using reactive forms, so 'debounceTime' pipe works pretty fine for me.
Also you need to set control's internal value to the updated one explicitly after normalization, at least, for reactive forms.
Another option could be removing the focus off the year part or control each time after normalization. This will ensure that typed and normalized value will be synchronized with the internally cached by input.

But I agree that all this should be handled by the control itself internally, instead of dancing tango with all these workarounds.

[PeterStaev]

@zhaparoff ,
Sadly in my case it does not work, even with the debounce:
https://stackblitz.com/edit/kendo-angular-shortdates?file=app/app.component.ts
1. Enter 2/22/15 - this correctly changes to 2/22/2015 and the year remains focused
2. Type 19 - year gets changed to 1519...
This is when you use the default format for year yyyy. If you change the format to M/d/yy then you get the year 519...
See update in next comment

[PeterStaev]

Ok, after a bit of a struggle with this I think finally made it to work nicely. Currently the date input/picker has some strange way of inputting numbers - while you are in the control it will just append the numbers you type to the value in the current focused segment and this will be evaluated to be the new value. Once you blur the control, the input starts to work again as replace for each segment.
This directive makes it so that after the given debounce time the values in the segment will be replaced and not appended and also normalizes 2 digit years to 20XX:
https://stackblitz.com/edit/kendo-angular-shortdates?file=app/short-date.directive.ts

[tsvetomir]

We're working on a fix and would love to hear your opinion on the following issue:

Q: Should the DateInput auto-correct two-digit numbers when the mask is 'yyyy'?

Pros:

• The century will be assumed regardless of the chosen format.

Cons:

• Years in the range 0 - 99 must be entered as "00", "099".

[zhaparoff]

In terms of the interface contract validity and accuracy, user should be able to input date only in format defined by the _formatPlaceholder_ setting.

If it says 'yyyy' - user should be forced to use full year notation, assuming that input will be mainly used for entering dates in different centuries. If short year pattern is set ('yy') - that means that control will be used only for dates from current century. Although display format (_format_ setting) could be any: short, long or whatever else for both cases.

Otherwise, we won't be able to guarantee invariant behaviour for the same input.

The only case, when suggested functionality would be reasonable, is if there will be settings to disable this auto-correction and to set some debouncing delay. So when typing 1-8-1-5 quickly it would NOT resolve to 2018 and 2015 after that, but Instead it will require some typing delay after 2-digit input, to auto-correct it to 4-digit.

And what if user will type '123'? Should it resolve to '0123' or to the current millenium '2123' by default, to keep that logic consistant?
How it will handle the case, when additional symbols were typed mistakenly: '12345' or '123456'? Although this is a mistake, but it can affect the subsequent input, as it is now, because the control is statefull and is not always flushing the internal input buffer.

Anyway, whithout additional options, giving the ability of full and flexible control over this feature from developer side, it will make more harm than benefits.

[JaapMosselman]

Yes it should autocorrect in my opinion, but only when leaving the year field. Not when the cursor is still in the field. That way the debounce is not needed which @zhaparoff suggested, I think.
But perhaps it is a good idea enable this only with a setting. Disabled by default, so you will not break current code.

[tsvetomir]

Thanks for your input!

We are also leaning towards an option as a safe way to enable this behavior. The only problem I see with it is that enabling it by default, even only for 'yy', would still be a breaking change. It's probably best to keep it disabled by default.

You can try out the experimental build in StackBlitz to get a feel for it. It's not final by any means and doesn't have a flag to disable the behavior.

You'll notice that there's no delay, instead the correction is applied in real time using the following rules:

• Values between 0 and 68 (user-configurable) are treated as 20xx, larger values as 19xx.
• A leading zero disables the auto-correct
• 3 or more digits disables the auto-correct. Entering '123' will be interpreted as 123 and additional digits will "shift" the value to the left.

[PeterStaev]

I am with @JaapMosselman comment above - it should auto correct but w/o the debounce time.

@tsvetomir , the StackBitz works really nice with one exception:

1. Focus the first dateinput
2. Enter 2, 22, 85
3. This changes the bound date to 2/22/1985 which is ok
4. Now the selection is at the year 1985. At this point type 3. This changes the year to 9853, which in my opinion should not happen. Instead the year should be changed to 2003

[zhaparoff]

@tsvetomir,

Typing '2121' to the 2-digit year template ('yy') sets year to '0121', which is wrong.
It should be '2121' or at least '2021', if we are assuming that current century is always used for 2-digit dates. Typing digit pairs with the big delay - few seconds - leads to the same behaviour.
So when user types '21', than corrects it to '20' after some delay (just a typing mistake), but control saves '120' into the database and user even doesn't know about it - he sees only last two digits - '20' in UI. This is unacceptable.

It is good that you trying to implement new functionality, but I'd like to have stable and reliable existing one before. The issue described in this particular ticket is still not addressed.

Moreover, after a bunch of experiments, I'm totally confused, what the option 'formatPlaceholder' controls? Date is always presented as specified in 'format' option, regardless of focus and _formatPlaceholder_ value. Placeholder is always displayed 'as is', and that's fine, because it is just asome text.

Actually, I'd like to see separate settings for _Display Format_ and _Input Format_ better than some mysterious auto-correction, which is hard to predict and make work correctly in all possible cases.
This way we can achive things like:

• inputting short date, but converting it into long: _Input Format = 'yy'_, _Display Format = 'yyyy'_
• inputting long date, but displaying it as short: _Input Format = 'yyyy'_, _Display Format = 'yy'_

Most likely my opinion isn't representative, but I'm usually turning such autocorrections off in all applications. They really make more harm than benefits, as for me, considering that they physically can't work correctly in all cases, so they are not reliable at all. Highlighting errors - is fine. Autocompletion, when a list of options is suggested - fine as well. Replacing something without considering my thoughts - NO, unacceptable. I believe, humans are smart enough, to decide what they are typing themselves, especially, when it is related to numbers and dates.

Sorry for another longread here. But broken autocorrections, which they are in majority of cases, enrage me.

[tsvetomir]

1. This changes the bound date to 2/22/1985 which is ok
2. Now the selection is at the year 1985. At this point type 3. This changes the year to 9853, which in my opinion should not happen. Instead the year should be changed to 2003

@PeterStaev 9853 is a valid value, even if unlikely, so we can't dismiss it based on typing sequence alone. Moving the focus outside the input or in a different segment will reset the state and '3' will be interpreted as '2003' on the next entry.

Typing '2121' to the 2-digit year template ('yy') sets year to '0121', which is wrong.
It should be '2121' or at least '2021', ...

@zhaparoff Good catch - I guess 2021 makes more sense in the context of this feature.

The issue described in this particular ticket is still not addressed.

The original issue is in fact being addressed, two-digit year mask is another aspect of it that should be solved as well.

Separate display and input formats means that the input will change it's apparent value on focus and blur. This might cause more harm than good to the user. An extreme example is inputFormat="MM/dd/yyyy" displayFormat="dd/MM/yyyy", but even minor differences can make the user wonder what's going on.

As for formatPlaceholder, check out the demo in the API Reference.

_Edit:_ Support for multiple formats is also suggested in this feature request.

[tsvetomir]

I've updated the snippet to use the latest build - check it out.

Typing into an 'yy' segment will now assume the current or previous century. It will also "shift left" when typing more than 2 symbols in one go.

There's still no flag to toggle the behavior in the experimental build.

[PeterStaev]

@PeterStaev 9853 is a valid value, even if unlikely, so we can't dismiss it based on typing sequence alone. Moving the focus outside the input or in a different segment will reset the state and '3' will be interpreted as '2003' on the next entry.

@tsvetomir , yes it is a valid year, BUT the change to this year is not clear from user point of view. At the point when the year changes to the a full 4 digit year, from user point of view he sees that the whole year selected, and thinks that if he starts typing it will REPLACE the value. It simply does not make sense if I see 1985 selected, I type 3 and that this value will be appended to the end shifting all digits to the left.
The typing logic should be smart enough to detect that if a 4 digit year is present all the internal logic should be reset and start from scratch. This digit shifting is pretty awkward and impossible to explain to users that are used to work with dates like they do in Excel.

Also your comment that shifting to a different segment and retyping is partially incorrect - I just tried in the snippet after the year changed to 1985, and I mouse click on the day for example, then click on the year again and type 3 it still changes to the bad year. Only if you use keyboard navigation via [Tab] or [Shift+Tab] then it works.

[tsvetomir]

@PeterStaev the "shift left" behavior is indeed strange. I left it alone for the time being, but it makes sense to reset the value once the mask length is exhausted.

[zhaparoff]

Separate display and input formats means that the input will change it's apparent value on focus and blur. This might cause more harm than good to the user. An extreme example is inputFormat="MM/dd/yyyy" displayFormat="dd/MM/yyyy", but even minor differences can make the user wonder what's going on.

_Edit:_ Support for multiple formats is also suggested in this feature request.

But in this case application developer has full control over how input will be parsed and how it will be displayed. My primary idea was to let user know (for example) that app is waiting year as two digits of current century, while displaying it as full year. Or instead, give an ability to input 4 digits (and verify input, when focused), while always displaying 2-digit format when not focused.
Specifying multiple input patterns will be a good option, as well.

But again, this is just an nice option, that can be handy as for me. If control will reliably process 'yy' pattern it won't be so necessary.

[clabough]

In the latest snippet, for the MM/dd/yy box, entering 1/1/09 results in 01/01/0009 but entering 1/1/9 results in 01/01/2009 but the display to the user is the same. They'd have no indication of what year it's actually generating. Entering 1/1/10 results in 01/01/2010.

It's a tough situation - when using only two-digit years, when to use previous century and when to use the current. If someone enters 40, do they mean 2040 or 1940, or enter 90, do they mean 1990 or 2090. Perhaps it should be a parameter of the control to set the two-digit roll-over year.

[tsvetomir]

@clabough the twoDigitYearMax setting can be used to customize this behavior. For example, setting [twoDigitYearMax]="2030" means that any value greater then 30 will be treated as 19xx. The default value is 2068. See the updated demo.

[JaapMosselman]

@tsvetomir that twoDigitYearMaxis not very flexible. I whould propose a max indicated by an offset from the current year.
So e.g. an twoDigitYearMaxOffsetof 10 would give a max of 2029. But if we are in 2025, the max will be 2035. The default value for this offset can be 49 (so this year the max would be 2068)

[tsvetomir]

@JaapMosselman I find the existing property already hard to explain. Using a relative value would make it even more complicated. It would be easier to explain if the calculation is in the app code:

<kendo-dateinput [twoDigitYearMax]="yearMax"

public yearMax = new Date().getFullYear() + 49;

[clabough]

For relative value, I think [twoDigitYearOffset] would make more sense.

[PeterStaev]

So more than half a year later, when can we expect a good resolution for this that works with 4 digit years? The current behavior is totally not intuitive to end users...

[JaapMosselman]

Any progress?

[tsvetomir]

No, sorry! We're finally getting around to this after a shamefully long pause.

[tsvetomir]

Shipped in v5.0.0, see documentation. Kudos to @dimitar-pechev 🙇‍♂️

• Using a two-digit year format would auto-correct to the current or previous century based on twoDigitYearMax.
• You can specify a separate display format so the change is more visible to the user.

<kendo-dateinput [format]="{ displayFormat: 'dd/MM/yyyy', inputFormat: 'dd/MM/yy' }">
</kendo-dateinput>