The subject should tell everything. Currently each locale comes with its specific "default". This creates confusion again and again, aggravates community help, causes time-wasting there, and ecourages the perpetuatiuon of outdated stubborn formats. There will soon be more and more cases where the century becomes unclear even for dates that were "current" once when data keeping was already done with computers. Does nobody remember the "y2k" confusion? A special case is the ambiguity created by the US "standard". Counter-standard date formatting can cause very serious problems if it afflicts data exchange via csv-styled files. Of course, we can't assume people will drop bad habits as soon as the requested feature is available. However, people who want to get it better would be supported and encouraged. BTW: An extremely absurd way to show date and time related information is how the sofware and the settings(?) used by the ask.libreoffice site does it. People may even be mislead to believe that's also a "standard".
*** This bug has been marked as a duplicate of bug 131332 ***
(In reply to m_a_riosv from comment #1) This can't be a dupe of bug 131332. That one is about changing some examples in help. This one is about new functionality in core.
Ok, sorry.
+1, it is never too late to start doing things properly.
Strong support for such an option. I would definitely use it. UX/Design team, how would you picture this? I guess we should also decide if such a setting would also influence (date-)time format or if it should be kept separate.
(In reply to Stéphane Guillou (stragu) from comment #5) > ... > I guess we should also decide if such a setting would also influence > (date-)time format or if it should be kept separate. I would argue in favor of applying the default to the combination of date and time as well, but not requiring the ISO “T” as the separator between date and time.
(In reply to Wolfgang Jäger from comment #6) > (In reply to Stéphane Guillou (stragu) from comment #5) > > ... > > I guess we should also decide if such a setting would also influence > > (date-)time format or if it should be kept separate. > > I would argue in favor of applying the default to the combination of date > and time as well, but not requiring the ISO “T” as the separator between > date and time. I agree that ISO 8601 ordering (large-to-small) without the time designator would be better as a default (since it's the de-facto international standard) but it should still be present if the user sets the format as 8601 explicitly.
Where exactly should the format come in play? Like Calc =TODAY() or Writer Field > Date (fix) returning 2024-06-06 instead of 06.06.2024 (depending on the locale).
I'd say wherever currently the default locale's default date(+time) format is used, not touching any assigned formats. Note this is related to long-standing bug 46448 but might be much easier to implement than that free-form extra layer of overriding details, as all locales already know the ISO 8601 date+time formats and there are mechanisms in place to switch to it, i.e. when a date was entered such.
Also, when activated there should be a second option (default on) to actually apply the ISO format to newly entered date(+time) cells to make it persistent even when loaded in a version or setting without that option activated, to propagate the format and be consistent when exchanging documents. Switching the option back and forth to change display strings in that case would not be possible. The result may be slightly confusing though when loaded in another setting as already existing date cells would keep their "use default locale's default format" status, which independently could be solved by offering a format replacement feature in the Find&Replace dialog, similar to Cell Styles.
(In reply to Eike Rathke from comment #10) > Also, when activated there should be a second option (default on) to > actually apply the ISO format to newly entered date(+time) cells to make it > persistent I suppose, that this should not be part of this bug. The proposed checkbox is in fact orthogonal, and is applicable the same way just to *any* default format, not only to a "date using default format, when the user chose to use ISO-8601 as their default". The proposal effectively resolves the automatic formats into fixed formats; and there is a value in both: the author may want to use automatic formats - to allow the recipient to see the values in a way that is most comfortable to them; or the author may want their document to have a fixed look - and that is actually best done by not using automatic formats at all, so IMO the proposed checkbox is not needed, one already needs to use explicitly chosen formats when they create fixed-looking documents.
(In reply to Mike Kaganski from comment #11) > IMO the proposed checkbox is not needed, one already needs to use explicitly > chosen formats when they create fixed-looking documents. This would be one of the options in Writer Edit Field > Format (not offering ISO8601) or one of the two last options in Calc Format Cells?
(In reply to Heiko Tietze from comment #12) Right. In case of Writer, the Format list has "Additional formats" element.
Yes, there it is. WFM?
(In reply to Heiko Tietze from comment #14) Of course no! Comment 11 was only discussing comment 10, which extended the original proposal. Why would that make the rest suddenly WFM???
Just noting that bug 46448 has at least three duplicates that ask for the exact same thing, making it easy to use ISO 8601 as an override of the locale's default date format: bug 149320, bug 127572 and bug 41044.
Then I suggest to add this request too.
(In reply to Heiko Tietze from comment #17) If the idea is to add this bug as another duplicate of bug 46448: please don't. Please read comment 9, and comment 16. Together, they show that this one can be implemented independently (or easier), and would satisfy a large chunk of users on its own; so closing this as "we need to fix a larger and harder issue, which will fix this, too" would miss this opportunity completely.
UX input is clear: add an option for the default date/time appearance with entries mm-dd-yyyy hh:mm, yyyy-mm-dd hh:mm, dd.mm.yyyy hh/mm, etc. defaulting to what the locale defines. I suggest to put all these tweaking options in an expander so it wont be too frightening for basic users. Up to QA whether this is part of bug 46448 - Allow custom locale settings... or a separate issue.
(In reply to Heiko Tietze from comment #19) > UX input is clear: add an option for the default date/time appearance with > entries mm-dd-yyyy hh:mm, yyyy-mm-dd hh:mm, dd.mm.yyyy hh/mm, etc. > defaulting to what the locale defines. Sorry, but this makes no sense. The request here is to add _one_ option to display ISO 8601 formats instead of the current default locale's defined formats. If the option is off (default), the current behaviour of using the locale defined formats still would be in effect. > I suggest to put all these tweaking > options in an expander so it wont be too frightening for basic users. There would be no further tweaking options for this.
Your idea of a checkbox or two radio buttons ("one option") limits the request to either locale or ISO. But ISO 8601 is just one way to format date/time values, and not only bug 46448 asks for more freedom but I can easily think of a use case where people have a locale of Klingon but want to get date/time values always in a specific format. While this particular request here is limited, the dropdown with all available formats (plus Automatic or Locale Default) is more flexible and is not detrimental on usability.
(In reply to Heiko Tietze from comment #21) > Your idea of a checkbox or two radio buttons ("one option") limits the > request to either locale or ISO. Great! You got it. > But ISO 8601 is just one way to format date/time values, and not only bug 46448 > asks for more freedom but I can easily think of a use case where people have a > locale of Klingon but want to get date/time values always in a specific format. Your "I can easily think of a use case" is exactly bug 46448, so it is not "not only bug 46448 asks", but exactly "there is a *related but different bug 46448*". > While this particular request here is limited, the dropdown with all available > formats (plus Automatic or Locale Default) is more flexible and is not > detrimental on usability. So *your* idea is: let us do all or nothing. Let us ignore the normal practice of having *important cases* (like all those specific field types available separately, even though there is a Fields dialog that has them all). Let us ignore the situation where the dev input has been given. Let us imagine a "dropdown with all available formats" (as if your imagined dropdown could truly hold *all* available formats, including my custom "day: "D", month: "MMMM" of year "YYYY)... And finally, your idea is "do not implement something easily doable; better stall forever, waiting for some ideal solution in the undefined future".