When I type in a date or time value in LibreOffice - not by formatting a cell, but by typing in, say, 2025-03-06 or 15:31 - I expect LibreOffice to recognize the nature of this input, i.e. keep track of it being a date value or time value. However, if I select a cell into which I've entered a date or time value, then on the menus choose Edit > Clear Direct Formatting - the date is converted into an integral number (in the case of a date) or a fractional one (in case of time or date-time); for example, 45722 and 0.646527777777778 for the date and the time I mentioned above. This is a bug. That is, the date-ness, or date-nature, of what I've entered is not an aspect of its formatting. The question of how to display it, i.e. as YYYY-MM-DD, days since some epoch, or something else - that's formatting. Now, unless the default format for a date is days-since-epoch (which I don't know to be the case) - there is no reason why clearing direct formatting would reformat 2025-03-06 and 45722. Specifically, as a user, while I did choose some date format to enter my date in, which could be construed as a formatting choice - I most definitely did not intend to enter 45722 with some direct formatting. It is almost certainly against my intent and my needs to change 2025-03-06 into 45722 when I want to clear DF such as spacing, font, vertical placement and number formatting (unlike, say, changing 2025-03-06 to 03/06/25 because that's the default date format for my locale, or whatever). No less importantly - the saved ODT file must indicate this value as a date, not just an arbitrary number. This is not what happens. Saving as an FODT, we get (in addition to a large amount of boilerplate/junk): <office:spreadsheet> <table:calculation-settings table:automatic-find-labels="false" table:use-regular-expressions="false" table:use-wildcards="true"/> <table:table table:name="Sheet1" table:style-name="ta1"> <table:table-column table:style-name="co1" table:default-cell-style-name="Default"/> <table:table-row table:style-name="ro1"> <table:table-cell office:value-type="float" office:value="45722" calcext:value-type="float"> <text:p>45722</text:p> </table:table-cell> </table:table-row> </table:table> <table:named-expressions/> </office:spreadsheet> So, a float value of 45722. That is not the user intended to put in their spreadsheet.
Hallo **clear Direct Formatting** means **clear Direct Formatting** fullstop! In case your User wish to apply Standard-Date-Format so they: * should apply some respective Cell-STYLE (recommended) * or hit **twice** the Date-Format-Button in the Toolbar for both cases ( and also for only implicit formatting by input **iso-dates** ) the **date**attribut is applied to the xml-nodes: ``` <table:table-row table:style-name="ro1"> <table:table-cell office:value-type="date" office:date-value="2025-03-16" calcext:value-type="date"> <text:p>16.03.25</text:p> </table:table-cell> <table:table-cell/> <table:table-cell office:value-type="date" office:date-value="2025-09-08" calcext:value-type="date"> <text:p>2025-09-08</text:p> </table:table-cell> ``` ( I understand clearly your complaint, but it is close to impossible todo what $User may have in mind )
(In reply to Werner Tietz from comment #1) > ( I understand clearly your complaint, but it is close > to impossible todo what $User may have in mind ) It's not close to impossible, it _is_ impossible, at the moment - because LO treats dates as no more than formatted numbers. Otherwise I would have filed a bug about making it easier. > **clear Direct Formatting** means **clear Direct Formatting** fullstop! Indeed, but clearing formatting must not make a simple number from a date. > In case your User wish to apply Standard-Date-Format That's only incidentally the case. In my case, the user wants to do what they say they want to do: Clear any formatting that was applied directly. > * should apply some respective Cell-STYLE (recommended) They don't want to apply some particular cell style; and the cells in the selected range may have different styles, which should of course should not be replaced. * or hit **twice** the Date-Format-Button in the Toolbar ... and would not want to do this either, since the range of cells includes many non-date cells.
(In reply to Eyal Rozenberg from comment #2) > It's not close to impossible, it _is_ impossible, at the moment - because LO > treats dates as no more than formatted numbers. Otherwise I would have filed > a bug about making it easier. Calc knows exactly 2 types of data: Text and floats. > > > **clear Direct Formatting** means **clear Direct Formatting** fullstop! > > Indeed, but clearing formatting must not make a simple number from a date. what else than a float? > > > > In case your User wish to apply Standard-Date-Format > > > That's only incidentally the case. In my case, the user wants to do what > they say they want to do: Clear any formatting that was applied directly. > > > * should apply some respective Cell-STYLE (recommended) > > They don't want to apply some particular cell style; and the cells in the > selected range may have different styles, which should of course should not > be replaced. > > * or hit **twice** the Date-Format-Button in the Toolbar > > ... and would not want to do this either, since the range of cells includes > many non-date cells. In other words: $User wants to select any random mix of Input ( including random mix of Formatting ) and calc should call $AI to resolve the Formatting-issues?? I'm out!
I've set the Status to »NOTABUG« feel free to reopen it.
(In reply to Werner Tietz from comment #3) > what else than a float? A _date_ (or datetime) value, of course! Please re-read the title. Intuitively, for users, a date is not a number; it is a combination of numbers, typically year, month and day (but that depends on the calendar of course). In software, it also often the case that a date is not just a number: Languages such as C++, Javascript and Python use (by default) non-integer types for dates. Of course, internally, every kind of information is eventually represented by bytes interpreted somehow. But that does not mean that "clearing the formatting" degenerates a date into a number.
Date/Time is a visual representation of a floating value. We had this discussion in bug 163723. (In reply to Eyal Rozenberg from comment #2) > (In reply to Werner Tietz from comment #1) > > ...it is close to impossible todo what $User may have in mind > It's not close to impossible, it _is_ impossible, at the moment... What exactly do you want UX to contribute here?