Bug 89609 - Explorer shell extension fails to convert date into locale specific string (sub-second precision ISO date → "strange date-information")
Summary: Explorer shell extension fails to convert date into locale specific string (s...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All Windows (All)
: medium normal
Assignee: Muhammet Kara
URL:
Whiteboard: target:5.2.0 target:5.1.3
Keywords: difficultyBeginner, easyHack, skillCpp
Depends on:
Blocks:
 
Reported: 2015-02-24 08:44 UTC by Thomas Krumbein
Modified: 2017-02-14 08:57 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Fileinfos on win 8.1 (21.51 KB, image/png)
2015-02-24 08:44 UTC, Thomas Krumbein
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Krumbein 2015-02-24 08:44:51 UTC
Created attachment 113634 [details]
Fileinfos on win 8.1

storing an open-document file on Windows 8.1 delivers strange date-informations in Windows explorer.
That may couse failure on searching informations with third party programs.

example picture: Writerfile stored as odt. 

expected behavior:  "23.02.2015 13:56"

seen behavior (screenshot):  "2015-02-23T 13:56:52.37800000"

Windows 8.1, Libo 3.5.6.
Comment 1 Adolfo Jayme Barrientos 2015-02-24 19:31:27 UTC
Thank you for your bug report.
Comment 2 Gordo 2015-03-15 13:58:29 UTC
The Modified date in the Windows OS File -> Properties -> Document Statistics dialog also shows the unformatted date.  It probably references the same variable.
Comment 3 Christian Lohmaier 2015-07-01 11:15:51 UTC
Code that retrieves the date for the tooltip is in 

http://opengrok.libreoffice.org/xref/core/shell/source/win32/shlxthandler/infotips/infotips.cxx#258

where it gets the modified date and tries to convert it into a local representation by calling the corresponding helper function:

 msg += iso8601_date_to_local_date(meta_info_accessor.getTagData(META_INFO_MODIFIED ));

However, iso8601_date_to_local_date as implemented here

http://opengrok.libreoffice.org/xref/core/shell/source/win32/shlxthandler/util/iso8601_converter.cxx#iso8601_date_to_local_date

doesn't expect sub-second precision date-string, but instead only expects 19 characters.

As the passed date is longer, the function doesn't do anything and instead returns the ISO date as it was passed into.
Comment 4 pierre-yves samyn 2015-07-01 17:13:36 UTC
Hi

I do not reproduce on windows 7/64 & Version: 5.0.0.2.0+ (x64)
Build ID: 18d6d789cae7cd684156dbd41d473892bc17392c
Locale: fr-FR (fr_FR)

Regards
Pierre-Yves
Comment 5 Robinson Tryon (qubit) 2015-12-13 10:57:59 UTC Comment hidden (obsolete)
Comment 6 Robinson Tryon (qubit) 2016-02-18 14:52:13 UTC Comment hidden (obsolete)
Comment 7 Muhammet Kara 2016-04-02 23:59:42 UTC
I confirm the bug exists in LO 5.0.4.2 (x64) on Windows 10.
Comment 8 Muhammet Kara 2016-04-18 12:29:19 UTC
What should we do here?
* Ignore the milliseconds, and parse the inputted ISO date down to seconds?
* Or check for existence of the milliseconds part, and also parse it?
Comment 9 Christian Lohmaier 2016-04-18 12:53:32 UTC
milliseconds and even seconds are irrelevant to the user (as this is for the tooltip in Windows explorer)

The patch should ignore the milliseconds/produce the same result as on windows 7 or older:

expected behavior:  "23.02.2015 13:56"

so the conversion function linked above should just ignore the fraction of seconds as it does now (it just sets milliseconds to 0) - but of course it must be changed to except that longer string as valid input.
Comment 10 Muhammet Kara 2016-04-18 14:31:09 UTC
(In reply to Christian Lohmaier from comment #9)
I have added an if block to check if the milliseconds part exists, and to remove if so. Please see it on gerrit: https://gerrit.libreoffice.org/24220

What do you think? Is it too complicated? The alternative would be something like just replacing "==" with ">=".
Comment 11 Commit Notification 2016-04-19 08:39:30 UTC
Muhammet Kara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=97dee1df42dc2933d1350eb1e67361674614417a

WIP tdf#89609 Ignore subsecond precision in iso8601

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 12 Commit Notification 2016-04-19 23:07:41 UTC
Muhammet Kara committed a patch related to this issue.
It has been pushed to "libreoffice-5-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=95a8f1bb0ad7c040b2c96ef0a509dd74dfe16fd7&h=libreoffice-5-1

tdf#89609 Ignore subsecond precision in iso8601_date_to_local_date

It will be available in 5.1.3.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 13 Muhammet Kara 2016-04-30 20:43:35 UTC
Fixed on master (5.2.0) and backported to fresh (5.1.3.). I have also tested it on Win10 64 bit with a daily build. Seems OK.

[0] http://cgit.freedesktop.org/libreoffice/core/commit/?id=97dee1df42dc2933d1350eb1e67361674614417a
[1] http://cgit.freedesktop.org/libreoffice/core/commit/?id=95a8f1bb0ad7c040b2c96ef0a509dd74dfe16fd7&h=libreoffice-5-1