Project

General

Profile

Actions
Copy link

Feature #38231

closed

Limit the year to 4 digits in date input

Added by Go MAEDA about 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
Go MAEDA
Category:
UI
Target version:
5.1.0
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
Fixed

Description

Date input fields such as Start date and Due date accept up to 6 digits as a year.

The problem with this is that, for example, when the current date format is YYYY/MM/DD, the cursor automatically moves to the next DD part when a two-digit number is entered in the MM part, but not when a four-digit number is entered in the YY part. So, users should enter TAB to move the cursor from YYYY to MM. This UI inconsistency leads to erroneous input such as "202302-01" when you input "2023-02-01".

In Google Chrome and Microsoft Edge, this can be improved by set `max="9999-12-31"` to `<input type="date">` tags. When `max="9999-12-31"` is set, the cursor moves from YYYY to MM immediately after you finish entering the fourth digit in YYYY. The attached patch sets `max="9999-12-31"` to all date input fields.

The disadvantage of this patch is that you will not be able to enter a year with more than 5 digits, but this should not be a problem since I think that project management rarely deals with dates 8000 years in the future.

Files

Download all files
limit-year-to-4-digits.patch (2.13 KB) limit-year-to-4-digits.patch Go MAEDA, 2023-02-01 15:30
limit-year-to-4-digits-v2.patch (2.15 KB) limit-year-to-4-digits-v2.patch Go MAEDA, 2023-03-29 06:26
Actions
Copy link
 #1

Updated by Holger Just about 1 year ago

Rather then using options.merge(max: '9999-12-31'), I'd propose to use options.reverse_merge(max: '9999-12-31'). That way, callers of the date_field and date_field_tag helpers can still provide a custom max value if required which will then take precedence before the default value 9999-12-31.

Apart from that, this looks good to me and is a nice unintrusive improvement. Not being able to enter dates almost 8000 years in the future should not be an issue for us.

Actions
Copy link
 #2

Updated by Go MAEDA about 1 year ago

Holger Just wrote in #note-1:

Rather then using options.merge(max: '9999-12-31'), I'd propose to use options.reverse_merge(max: '9999-12-31'). That way, callers of the date_field and date_field_tag helpers can still provide a custom max value if required which will then take precedence before the default value 9999-12-31.

Thank you for the suggestion, I didn't know reverse_merge. It is a more desirable behavior.

Setting the target version to 5.1.0.

Actions
Copy link
 #3

Updated by Go MAEDA about 1 year ago

  • Status changed from New to Closed
  • Assignee set to Go MAEDA
  • Resolution set to Fixed

Committed the patch.

Actions
Copy link

Also available in: Atom PDF