[Libreoffice-bugs] [Bug 135826] EDITING: Copy and paste a cell changes the content from '27-Jul-93' to '27-Jul-89'

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=135826

--- Comment #13 from Eike Rathke <erack at redhat.com> ---
(In reply to Wolfgang Jäger from comment #12)
> I would doubt if this helps reliably. There is no value-type Date or
> DateTime in Calc, and the the related NumbrFormat types (2 through 7) are no
> safe surrogate, because any user can use different NumberFormat types
> suitable for the purposes.
And any number format using at least one of the date format codes is
categorized as date format, so that is no exception to what I mentioned.

> Unfortunately a fomula like ="2001-11-18" - 14878
> is accepted by Calc,
That depends on the detailed calculation settings, whether on-the-fly
conversion from text to numeric is allowed or not, and how. My recommendation
is to set that to "Always generate #VALUE! error" (and use DATE() in this
case), but it will break a gazillion existing Excel (and Calc) documents, but
is the best setting to spot errors early.

> and neither Calc's automatisms nor the supposed user
> will format the result as date. The result will depend on the .NullDate
> setting, however. 
The result *number* (serial date number) yes, if interpreted as date e.g. for
display then no, the displayed date will be the same. Conversion from
"2001-11-18" to the serial date number involves the current null date, from the
resulting date serial the number 14878 is subtracted and the result is
displayed adding it to the null date.

> Without going into the Tokens of every formula cell there is no way to solve
> the prpoblem technically.
Which wouldn't help here either, because it's just a string token.

> And what about value-only-copies of such cells?
Yes, that will be different, and there's not much that could be done.

> Since there is no satisfying solution to the problem itself, there should be
> at least an enhancement helping to avoid serious errors which may occur if
> the mentioned behaviour lead to an unnoticed offset of 1462 days.  
> 
> When copying cell ranges from sheet to sheet and also when moving or copying
> complete sheets from one document to a different one, Calc should check the
> .NullDate settings of both documents and warn the user.  

That would be a possibility.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210325/52128831/attachment-0001.htm>