<html>
    <head>
      <base href="https://bugs.documentfoundation.org/">
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_UNCONFIRMED "
   title="UNCONFIRMED - [Calc] Date acceptance pattern error"
   href="https://bugs.documentfoundation.org/show_bug.cgi?id=126342">126342</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>[Calc] Date acceptance pattern error
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>LibreOffice
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>6.2.5.2 release
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>All
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>All
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>UNCONFIRMED
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>normal
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>medium
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>Calc
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>libreoffice-bugs@lists.freedesktop.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>Spampot@gmx.net
          </td>
        </tr></table>
      <p>
        <div>
        <pre>Description:
One of the recent LO releases (I suspect 6.2.5 or 6.2.4) introduced the
following misbehavior when entering a date into a Calc cell. I have never
observed this bug in earlier releases.

Steps to Reproduce:
1. Format a cell as
- Category = Date
- Format = 1999-12-31 (Format code "JJJJ-MM-TT", ISO 8601)
- Language = German (Germany)

2. Click the empty cell and enter a date using German style
"<Day>.<Month>.<2-digit year>", e. g. "11.7.19".
The pattern is correctly recognized and displayed as "2019-07-11", as it has
always been in previous versions of LO.

3. Now that the cell is no longer empty, click it again and overwrite the
existing date with the exact same input as above, "11.7.19".

Actual Results:
The same input is now incorrectly interpreted as "<Year>.<Month>.<Day>" and
displayed as "2011-07-19" (instead of the correct "2019-07-11").

Expected Results:
The input should have been correctly interpreted as "2019-07-11" again. Date
acceptance patterns shouldn't depend on the previous content of a cell.


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 6.2.5.2 (x64)
Build ID: 1ec314fa52f458adc18c4f025c545a4e8b22c159
CPU threads: 8; OS: Windows 6.3; UI render: default; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>