I am using a html5 native datepicker which does almost everything what I need, which includes
- Assisted keyboard operability (it jumps from month to date to year without having user enter the separator),
- localization (different languages are supported as per system language),
- auto-correction of dates (if user enter month as 13, it auto corrects it to 12)
- date-picker display is also keyboard operable (I can navigate from one month to another and one date to another via keyboard)
- browser support is good (almost all latest versions of most known browsers supports it)
- shows rolling date picker on mobile device browsers.
But concern however is that
- Date format is not configurable programmatically, so application cannot control date format
- It responds only to system date format which is not readable by the application (it is a browser based application)
- User can select the date-format but since it doesn't affect the native datepicker format, so only display-format (labels) can use it. Format selection is not a user-level feature, it is done at organization level.
As a result, there is an inconsistency in date-display format and date-entry format. User cribs about it due to this inconsistency.
I can think of two approaches to deal with this issue
- find out a new date-picker that gives me all these features and replace my current native datepicker based implementation with that new one. This is an expensive option since a lot of time has already gone in it. Our final option is to develop our own plugin.
- (More preferably) Somehow communicate the user that this native datepicker can repond to system date format so that user can change the system date format. (what is the best way to communicate this to the user?)
Keeping in mind that this feature will be heavily used while doing data-entry and has high frequency of usage - Which approach is better? or How can I provide a graceful alternate to date format consistency?