Bug 130107 - CALC, WRITER: UI: date format examples are suboptimal
Summary: CALC, WRITER: UI: date format examples are suboptimal
Status: RESOLVED DUPLICATE of bug 38231
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
Depends on:
Blocks:
 
Reported: 2020-01-21 10:53 UTC by Mihkel Tõnnov
Modified: 2020-01-21 12:30 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mihkel Tõnnov 2020-01-21 10:53:52 UTC
The chosen example date of 31 Dec 1999 produces unclear date format list for some formats in many locales, due to no leading zeroes existing in 31 or 12.
This applies both in Calc (Format Cells - Numbers - category: Date) and in Writer text tables (Table - Number Format - category: Date).

For example:

Catalan:
31/12/99 shown for both "D/MM/YY" and "DD/MM/YY"

Chinese (traditional):
1999/12/31 shown for both "YYYY/M/D" and "YYYY/MM/DD"

Dutch (Netherlands):
"D-MM-JJ" and "DD-MM-JJ"

English (US):
"M/D/YY" and "MM/DD/YY"
"NNNNMMMM D, YYYY" and "NNNNMMMM DD, YYYY"

Estonian:
"D.M.YY" and "DD.MM.YY"
"NNNNDD. MMMM YYYY. a" and "NNNND. MMMM YYYY. a"
"NN, D. MMM YY" and "NN, DD. MMM YY"

Finnish:
"P.K.VVVV" and "PP.KK.VVVV"
"NN P. KKK VV" and "NN PP. KKK VV"

Etc. etc.

Suggestions for a better example date:

a) 1 Jan 1999. I realize that this might cause confusion regarding DD/MM/YY vs. MM/DD/YY but frankly, there are only a few locales that use both: https://en.wikipedia.org/wiki/Calendar_date#Usage_map

b) 31 Jan 1999. This only partially solves the leading-zeroes issue (i.e. for only some of the date formats), but preserves the clarity of DD/MM/YY vs. MM/DD/YY if deemed necessary.

Additional discussion point: should the example year be modernized? I think it should in any case stay outside the range of 01...31, so one option would be to be futuristic and use a year between 2032...2100 (although this would in a way conflict with the default setting to interpret two-digit years as between 1930 and 2029).
Comment 1 sdc.blanco 2020-01-21 12:30:59 UTC

*** This bug has been marked as a duplicate of bug 38231 ***