* .xls spreadsheet All cells in a column are formatted as Number-General and contain a formula that simply subtracts one date from another to get elapsed days. When the result exceeds the width of the column and Format-Column-OptimalWidth is performed, the display format of *all* cells in the column is changed to the default date format; however, the actual format remains Number-General as shown by Format-Cell and as demonstrated when the column width is narrowed by dragging and the correct Number-General format is automatically restored.
NOT reproducible with a self exported .xls and "LibreOffice 3.3.1 RC1 – WIN7 Home Premium (64bit) German UI [OOO330m19 (build 7 / tag 3.3.1.1)]" @Randy: Please attach a sample document!
Created attachment 43576 [details] Sample document for Bug 34484 The circumstances of the action being experienced are more basic than initially reported. I have attached a sample document. It is a native .ods spreadsheet. It seems that the results of my date formula in a cell formatted as Numeric-General will appear in date format (dd/mm/yy) if the column has sufficient width. If the width is *less* than that required for date format, the format *defined* for the cell, Numeric-General, is used to display the value. It remains the case that if the cell with the formula is selected and Format-Column-OptimalWidth is performed, the width of the column is increased, if necessary, to accommodate the display of the date format.
It's the Today() function that causes a part of the strange behavior I created a more simple sample, dates have been inserted manually, F1 contains a calculation with a date and today() in it F2 contains a calculation with a date and the date of today created with today() in it in as separate cell. You see the differences between F1 and F2, - F1 contains "18.01.00" what is "18. Januar 1900" - F2 Contains No 19. It seems that today() causes some auto format, that disappears if column width is not sufficient? Same effect for an other date calculation formula "=DATUM(11;2;20)-D5", it seems that cells with date functions cause this effect. No idea what that might be good for, I can only see that "Ooo 3.3.0 – WIN7 Home Premium (64bit) German UI [OOO330m20 (build 9567)]" behaves in the same way. Bug or feature? I can't decide. If it's a feature, it's a worrying one.
Created attachment 43580 [details] See Comment 3
(In reply to comment #4) > Created an attachment (id=43580) [details] > See Comment 3 I concur. It does indeed seem that cells with date functions cause this effect: I experience the same result when date functions EOMONTH and EDATE are used. If it is a feature and is retained, I suggest that consideration be given to making it an option and not the default.
I have discovered that the reported problem may be circumvented by placing the date calculation within a VALUE function, i.e., VALUE(date_formula).
This is an artifact of the auto decimal adjustment feature kicking in when the column width is not wide enough for the displayed date value. I'll look into it.
K. Hopefully fixed this for good, on master. Please test this when the first beta of 3.4 comes out. Thanks.
(In reply to comment #8) > K. Hopefully fixed this for good, on master. Please test this when the first > beta of 3.4 comes out. Thanks. Will do. Thanks!