2023-03-13, 21:12
When viewing the 'Regional' settings, the GUI shows previews of the current settings. When changing a setting, a preview list is also provided demonstrating what the available setting options will look like. This preview list is provided using the current date and, where appropriate, time.
The issue I have noticed is that when the day and/or month value is greater than 9, the preview is no longer indicative of the true on-screen appearance when single digit days and/or months are desired.
For example: The previewed value of a short date format of 'D/MM/YYYY' (non zero-padded day) is indistinguishable from that of 'DD/MM/YYYY' (zero-padded day) for most of the month.
I'd like to propose that instead of using the current date/time for previews, that a single specific date/time be selected that will highlight, more clearly, the zero-padding behaviour of each format.
The day, month, hour, minute and second should all be unique single digit values. This will help users identify zero-padded formats and either select or avoid them as per their personal preference. In addition to this, having different values for the day and month, the user should be able to differentiate between DMY and MDY formats more easily when viewed together with all of the available formats.
The next part of this suggestion is English-specific and may not be applicable to other languages:
The date chosen as a preview value should be a Wednesday as this is the longest spelled day name. Similarly, the month should be a September as this is the longest spelled single digit month. Selecting a date with the longest spelled values will also give the user an indication of how much screen real estate the format will consume in the worst case.
I'd like to propose "Wednesday 5 September 2007 01:02:03" as the preview date/time.
Each component is unique: day = 5, month = 9, year = 2007 (short year = 07), hour = 1, minute = 2 and second = 3.
I did for a moment consider including the formatting string with the preview, for example '01/02/2003 (DD/MM/YYYY)'. However, that solution would be locked into the Latin script because, regardless of the actual GUI language, this area of the language localisation file uses the Latin script.
Thoughts and comments welcome.
The issue I have noticed is that when the day and/or month value is greater than 9, the preview is no longer indicative of the true on-screen appearance when single digit days and/or months are desired.
For example: The previewed value of a short date format of 'D/MM/YYYY' (non zero-padded day) is indistinguishable from that of 'DD/MM/YYYY' (zero-padded day) for most of the month.
I'd like to propose that instead of using the current date/time for previews, that a single specific date/time be selected that will highlight, more clearly, the zero-padding behaviour of each format.
The day, month, hour, minute and second should all be unique single digit values. This will help users identify zero-padded formats and either select or avoid them as per their personal preference. In addition to this, having different values for the day and month, the user should be able to differentiate between DMY and MDY formats more easily when viewed together with all of the available formats.
The next part of this suggestion is English-specific and may not be applicable to other languages:
The date chosen as a preview value should be a Wednesday as this is the longest spelled day name. Similarly, the month should be a September as this is the longest spelled single digit month. Selecting a date with the longest spelled values will also give the user an indication of how much screen real estate the format will consume in the worst case.
I'd like to propose "Wednesday 5 September 2007 01:02:03" as the preview date/time.
Each component is unique: day = 5, month = 9, year = 2007 (short year = 07), hour = 1, minute = 2 and second = 3.
I did for a moment consider including the formatting string with the preview, for example '01/02/2003 (DD/MM/YYYY)'. However, that solution would be locked into the Latin script because, regardless of the actual GUI language, this area of the language localisation file uses the Latin script.
Thoughts and comments welcome.