Bug 112428 - After saving document, containing dates in cells, the document displays wrong date format if I open it in MS Office
Summary: After saving document, containing dates in cells, the document displays wrong...
Status: RESOLVED DUPLICATE of bug 113889
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.4.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, filter:xlsx, regression
Depends on:
Blocks:
 
Reported: 2017-09-16 13:06 UTC by H3xag0n
Modified: 2018-02-11 08:23 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
File containing dates in cells. Was created in MS Office 2010 and edited in Libre (5.50 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2017-09-18 00:33 UTC, H3xag0n
Details
File contents displayed in Libre (326.43 KB, image/jpeg)
2017-09-18 00:34 UTC, H3xag0n
Details
File contents displayed in MS Excel Viewer (304.25 KB, image/jpeg)
2017-09-18 00:35 UTC, H3xag0n
Details

Note You need to log in before you can comment on or make changes to this bug.
Description H3xag0n 2017-09-16 13:06:53 UTC
Description:
After saving document, containing dates in cells, the document displays wrong date format if I open it in MS Office. For example, in a cell of Calc sheet I have a date 31.08.2017. The format is "Date dd.MM.yyyy RU". I save the document in xls or xlsx. Then I open this document in MS Office 2007-2010. I see that date in that cell is displayed as 08.31.2017! The format is still "Date dd.MM.yyyy RU". However, LibreOffice displays this cell correctly.

Steps to Reproduce:
1. Run the Calc
2. Type the value "31.08.2017" in a cell
3. Right click on that cell, make format "Date dd.MM.yyyy RU" (just choose from the lists)
4. Save the file in xls or xlsx format.
5. Open the file in MS Office 2007, 2010 or just Excel Viewer.
6. You see that date in the cell looks like 08.31.2017

Actual Results:  
The date in a cell transforms from dd.MM.yyyy to MM.dd.yyyy format, when looking through MS Office 2007-2010

Expected Results:
LibreOffice should keep the format of a cell in a right format. MS Office should display theese cells with dates correctly.


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
Comment 1 raal 2017-09-16 13:14:19 UTC
I cannot confirm with LO 6, Linux and excel 2010. Please attach test file.
Comment 2 Xisco Faulí 2017-09-17 09:53:32 UTC Comment hidden (obsolete)
Comment 3 H3xag0n 2017-09-18 00:33:47 UTC
Created attachment 136325 [details]
File containing dates in cells. Was created in MS Office 2010 and edited in Libre
Comment 4 H3xag0n 2017-09-18 00:34:32 UTC
Created attachment 136326 [details]
File contents displayed in Libre
Comment 5 H3xag0n 2017-09-18 00:35:03 UTC
Created attachment 136327 [details]
File contents displayed in MS Excel Viewer
Comment 6 H3xag0n 2017-09-18 00:36:09 UTC
Hello!
I attached the file and 2 screenshots.
Comment 7 raal 2017-10-22 10:29:43 UTC
Confirmed in LO6, regression from LO 5.3:
create custom date format dd.mm.yyyy in excel,save as xlsx
open in LO, change date; save
open in excel ->date changed to format mm.dd.yyyy
Comment 9 Kevin Suo 2018-02-11 07:56:40 UTC
I do reproduce the bug in version:
Version: 5.4.0.0.alpha1+ Build ID: 9feb7f7039a3b59974cbf266922177e961a52dd1
(following the steps in comment 7)

But I do not reproduce it in the 6.0.1.1 release.

Could someone confirm?
Comment 10 Kevin Suo 2018-02-11 08:22:44 UTC
A reverse-bibisect (using the bibisect-linux-64-6.0 repo) shows the following result:

98750e33e483de40d996315433d6b7165ad742d6 is the first bad commit
commit 98750e33e483de40d996315433d6b7165ad742d6
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Fri Nov 17 02:07:16 2017 +0100

    source sha:0f73433b13ba9e3f38193ddd86f4b9b767a36bb2
    
    source sha:0f73433b13ba9e3f38193ddd86f4b9b767a36bb2
    source sha:eb8bd7f21103ed2349b44c954db977709de2e4ec
    source sha:f643e1f687e27e7f46c53d7298772d4dddb3e660

:040000 040000 278da5e338fbf740f716f3a7c3c8bac2bf84daea b94fef3df2752d563cd661279fc5d4ce567de965 M	instdir

Reverse bibisect log:

[suokunlong@x230i bibisect-linux-64-5.4-6.0]$ git bisect log
# bad: [cddc6665c4e33f5a18e7e1a02cd2799d95653f0a] source sha:47cc374c0659fd3db74a1b184c870eaa56bc385b
# good: [b9d78ce81dc3481fccb0cb75d76fcb6ac939cbd5] source sha:9feb7f7039a3b59974cbf266922177e961a52dd1
git bisect start 'master' 'oldest'
# good: [eb6680d85befc418b36f2cb00402f56a2472758f] source sha:c54850b23a8240a41755af171a6d3f990ee69f84
git bisect good eb6680d85befc418b36f2cb00402f56a2472758f
# good: [3fa1ae98ece9b3537df34742d3383aac834caf76] source sha:87c671d188f4a0f5dcc7944b450cc58e84217d81
git bisect good 3fa1ae98ece9b3537df34742d3383aac834caf76
# good: [9bc1a6bd3e4aafadd3a19ac4983952db039716f9] source sha:bff8d843bd4e5dcca5dc1a60c2c7852b1b72a00b
git bisect good 9bc1a6bd3e4aafadd3a19ac4983952db039716f9
# bad: [bfe61ba27238bbf4b276df17c8db76c088833fd9] source sha:57768926f344e516c039db9417d2cfd4c5e6b303
git bisect bad bfe61ba27238bbf4b276df17c8db76c088833fd9
# bad: [fa9401bbafb9f30f896be204bbd60c32e0525a5a] source sha:328cdfd4a75f5e29c3a1b3ba4ee0ed9475603442
git bisect bad fa9401bbafb9f30f896be204bbd60c32e0525a5a
# good: [8f7f88bb8ba548d4cc98d90bbaaa1e9e6000fd96] source sha:329eeefcbd65ea88f0c8c3f034d49ba73045d059
git bisect good 8f7f88bb8ba548d4cc98d90bbaaa1e9e6000fd96
# good: [c7d3717e777c2d425f9b3b735330539ccc1b3d29] source sha:29c21f6dd7b3c915c989102e7c790face1bae55f
git bisect good c7d3717e777c2d425f9b3b735330539ccc1b3d29
# bad: [6448f62fe90d3bb0ff414e01a7ad0c908f53b425] source sha:9da4b3ee827e83b816514e4eb071e5322cb5ad01
git bisect bad 6448f62fe90d3bb0ff414e01a7ad0c908f53b425
# good: [2e49861bece924ce3614be49ec787db566b09846] source sha:38d0142556dfb96465f70cabca9018780d9e810c
git bisect good 2e49861bece924ce3614be49ec787db566b09846
# good: [df1467cba7028b3b493b268b361ead1330439f8a] source sha:05fc30e38899348fb58548adb7a72e4fa2874d62
git bisect good df1467cba7028b3b493b268b361ead1330439f8a
# bad: [1582eaca9b26503093e60d0ac7185d7c54c07cc7] source sha:d552f67f5ee508ac6fbe03d16e6ba3ac429c3a48
git bisect bad 1582eaca9b26503093e60d0ac7185d7c54c07cc7
# good: [3d203fe4534aca1a40a0b3a46783c03c8f02b2b8] source sha:26ea47b7217053efb5eaa20f76b8895d29ae1f18
git bisect good 3d203fe4534aca1a40a0b3a46783c03c8f02b2b8
# bad: [98750e33e483de40d996315433d6b7165ad742d6] source sha:0f73433b13ba9e3f38193ddd86f4b9b767a36bb2
git bisect bad 98750e33e483de40d996315433d6b7165ad742d6
# first bad commit: [98750e33e483de40d996315433d6b7165ad742d6] source sha:0f73433b13ba9e3f38193ddd86f4b9b767a36bb2

This suggests that this bug is fixed by:
author	Eike Rathke <erack@redhat.com>	2017-11-17 00:16:17 +0100
committer	Eike Rathke <erack@redhat.com>	2017-11-17 00:17:04 +0100
commit	eb8bd7f21103ed2349b44c954db977709de2e4ec (patch)
tree	f872db70d10239b88c049a7caf9c34c14e9e8602
parent	f643e1f687e27e7f46c53d7298772d4dddb3e660 (diff)
Resolves: tdf#113889 no date particle reordering when exporting to Excel

(i.e., the previous commit before "the first bad commit").

Marking as a duplicate of bug 113889

*** This bug has been marked as a duplicate of bug 113889 ***