<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - EDITING: Copy and paste a cell changes the content from '27-Jul-93' to '27-Jul-89'" href="https://bugs.documentfoundation.org/show_bug.cgi?id=135826#c13">Comment # 13</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - EDITING: Copy and paste a cell changes the content from '27-Jul-93' to '27-Jul-89'" href="https://bugs.documentfoundation.org/show_bug.cgi?id=135826">bug 135826</a> from <a class="email" href="mailto:erack@redhat.com" title="Eike Rathke <erack@redhat.com>"> Eike Rathke</a> <pre>(In reply to Wolfgang Jäger from <a href="show_bug.cgi?id=135826#c12">comment #12</a>) > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>