<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p class="western" lang="en-US">Hi<br>
</p>
<p class="western" lang="en-US">A few weeks ago I proposed a patch
<a class="moz-txt-link-freetext" href="https://gerrit.libreoffice.org/c/core/+/138845">https://gerrit.libreoffice.org/c/core/+/138845</a> related to bug
tdf#150587, which removed what I felt was an artificial limitation
on
the range of dates that can be entered in some LibreOffice form
controls.</p>
<p class="western" lang="en-US">Due to some comments, I reverted the
patch and started to
do some testing of the behavior of dates in LibreOffice.</p>
<p class="western" lang="en-US">As a result of the tests I could
observe a number of errors:</p>
<ul>
<li>
<p class="western"><span lang="en-US">When exporting dates from
Calc to Writer database fields , out of </span><span
lang="en-US">8</span><span lang="en-US"> exported dates, </span><span
lang="en-US">2</span><span lang="en-US"> incorrectly
exported → </span><strong class="western"><span
lang="en-US">25 </span></strong><strong class="western"><span
lang="en-US">% errors</span></strong></p>
</li>
<li>
<p class="western"><span lang="en-US">When exporting dates from
Calc to a Base database, out of </span><span lang="en-US">8</span><span
lang="en-US"> exported dates, </span><span lang="en-US">3</span><span
lang="en-US"> are incorrectly exported → </span><strong
class="western"><span lang="en-US">37,5</span></strong><strong
class="western"><span lang="en-US"> % errors</span></strong></p>
</li>
<li>
<p class="western"><span lang="en-US">When opening with Base a
Firebird database table (created externally), out of1</span><span
lang="en-US">0</span><span lang="en-US"> data, 7 are
displayed incorrectly → </span><strong class="western"><span
lang="en-US">70</span></strong><strong class="western"><span
lang="en-US"> % errors</span></strong></p>
</li>
<li>
<p class="western"><span lang="en-US">If the above data is
displayed in a form, instead of in a table, all datas are
displayed incorrectly, </span><strong class="western"><span
lang="en-US">100 % errors</span></strong></p>
</li>
<li>
<p class="western"><span lang="en-US">When entering data in a
table in Base, </span><span lang="en-US">of </span><span
lang="en-US">6</span><span lang="en-US"> data entered, at
least 3 incorrectly show → </span><strong class="western"><span
lang="en-US">50 </span></strong><strong class="western"><span
lang="en-US">% errors</span></strong></p>
</li>
<li>
<p class="western">Of the 6 data entered above, 3 are saved
incorrectly, but curiously they are not exactly the same as
they were wrongly displayed →<strong class="western"> </strong><strong
class="western">50</strong><strong class="western"> % errors</strong></p>
</li>
</ul>
<p class="western" lang="en-US">Since all the data used in the tests
are extreme data, and therefore produce extreme errors, surely in
normal employment not so many errors occur. But although it,
cannot be
ruled out that similar errors occur in normal use of LibreOffice
components (they have occurred to me).</p>
<p class="western" lang="en-US">It is true that the normal procedure
when detecting errors should be to report them in bugzilla. But in
this case, in my point of view, before proceeding to qualify
certain
behaviors as errors or not, we have to decide what treatment we
want
to give to the date in LibreOffice.</p>
<p class="western" lang="en-US">Because, currently, on one hand,
each
of the LibreOffice components, or even parts of the same
component,
treat dates in a different way. For example, in Calc you can enter
almost all dates without any problem and dates are not modified
(only the dates not allowed are converted to text), while in Base
or
in Writer form controls, sometimes dates are modified without
warning.</p>
<p class="western" lang="en-US">And on the other hand, there are
components or controls that artificially limit the range of dates
they allow input, but, curiously, they can show dates that they do
not allow to enter. </p>
<p class="western" lang="en-US">It seems that this artificial
limitation imposed on the date range has been implemented to avoid
(and not to solve) problems with certain dates.</p>
<p class="western" lang="en-US">In conclusion IMHO, it should be
open a
debate and decide what treatment should be to give to dates and
apply
that decision in all LibreOffice components.</p>
<p class="western" lang="en-US">In my view the best solution would
be
to use the proleptic Gregorian calendar in all components and,
furthermore, not artificially limit dates to a relatively narrow
range of dates, but to be able to enter dates at least in the
range
between 0001-01-01 and 9999-12-31.</p>
<p class="western" lang="en-US">Sorry for the length.</p>
<p class="western" lang="en-US">Regards</p>
<p class="western" lang="en-US">PS: Attached a Writer document
explaining tests I have done and results (I'm not sure if
attachments are allowed) <br>
</p>
<p></p>
<div class="moz-signature">-- <br>
<font color="#2a6099"><font face="Liberation Sans, sans-serif"><font
style="font-size: 12pt" size="3"><b>Juan C. Sanz</b></font></font></font></div>
</body>
</html>