Bug 38693 - FILEOPEN xslx: document property TotalTime misinterpreted as seconds instead of minutes
Summary: FILEOPEN xslx: document property TotalTime misinterpreted as seconds instead ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.3.2 release
Hardware: Other Windows (All)
: medium trivial
Assignee: Ravindra Vidhate
URL:
Whiteboard: target:5.0.0
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-26 11:13 UTC by Andreas J Guelzow
Modified: 2015-05-11 06:57 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
sample file (5.13 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2011-06-26 11:13 UTC, Andreas J Guelzow
Details
Screenshots, See Comment 2 (131.94 KB, application/x-download)
2011-08-21 01:20 UTC, Rainer Bielefeld Retired
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas J Guelzow 2011-06-26 11:13:06 UTC
The attached xlsx file has the extended document property
<TotalTime>1</TotalTime>
in /docProps/app.xml

LibreOffice appears to read this as a a total editing time of 1 _second_ but according to ECMA-376 2nd edition:
22.2.2.27
TotalTime (Total Edit Time Metadata Element)
Total time that a document has been edited. The default time unit is minutes.

so this should be 1 minute.

(ECMA-376 1st edition has the same statement in  7.2.2.27)
Comment 1 Andreas J Guelzow 2011-06-26 11:13:49 UTC
Created attachment 48446 [details]
sample file
Comment 2 Rainer Bielefeld Retired 2011-08-21 01:19:11 UTC
After lots of irrelevant tests I found:

A1) Sample document can be used with LibO, Gnumeric, MS-XLS-Viewer without problems

A2) /docProps/app.xml of test document contains <TotalTime>1</TotalTime> (what ever that might mean.

B1) "LibreOffice 3.4.2  - WIN7  Home Premium (64bit) German UI [OOO340m1 
   (Build:203)]" shows document properties incomplete and damaged, especially
   time information is unusable (see screenshots!)
B2) Gnumeric only shows very few document properties information, irrelevant for
    the tests
B3) looks good with Master "LibO-dev 3.4.5 – WIN7 Home Premium (64bit) English 
    UI [(Build ID:d337f79-a24c961-2865670-9752b71-7f8fd43
	2fdd60d-fd28b6a-fd7bf20-aa369cb-28da3fb
	6a9633a-931d089-ecd263f-c9b55e9-b31b807
	82ff335-599f7e9-bc6a545-1926fdf)]" (see screenshots)
    But indeed "Total Editing Time" is shown as seconds, not minutes.


ECMA-376 is available from
<http://www.ecma-international.org/publications/standards/Ecma-376.htm>
In Part 1 "ECMA-376, Second Edition, Part 1 - Fundamentals And Markup Language Reference" I found reporter's reference. No changes here in Third Edition.

Reporter's OS unknown, so I modify to WIN (although I assume that it's the same for all)

@Andreas J Guelzow:
You could increase processing speed and ease our work if your would contribute complete information due to <http://wiki.documentfoundation.org/BugReport> with your reports. So it took more than 1 hour to find the core of your report, what should have taken 5 minutes with a complete report, that would have cost you additional 5 minutes.

@Kohei:
Please feel free to reassign (or reset Assignee to default) if it’s not your area. Please set Status to ASSIGNED if you accept this Bug.

Seems to be an EasyHack?
Comment 3 Rainer Bielefeld Retired 2011-08-21 01:20:22 UTC
Created attachment 50417 [details]
Screenshots, See Comment 2
Comment 4 Andreas J Guelzow 2011-08-21 01:35:12 UTC
@Rainer, what additional info were you looking for? 

I think I described the problem in total:
1) the file contained <TotalTime>1</TotalTime> in /docProps/app.xml
2) LibreOffice interprets this as 1 sec when
3) The standard clearly states that this is 1 minute.

What else did you need? The behaviour of other implementations is pretty much irrelevant in this case (and apparently you are using an old version of Gnumeric). A recent version would have shown you all properties in the file.

How does my OS matter in this case? And of course it is _not_ MSWindows but Linux.

I gather that you are not interested in bug reports so I will again stop filing them.
Comment 5 Kohei Yoshida 2011-08-22 07:28:18 UTC
IMO, Andreas' bug report is short and to the point, that contains all necessary information without being too wordy.  I'm not a big fan of unnecessary lengthy bug reports which takes time to read, so I prefer bug reports like this one.

Just FYI, Andreas is a well-known contributor to Gnumeric, and both Eike and I know him very well from the ODF TC.  So, I hope we can treat his bug reports a little more seriously.
Comment 6 Rainer Bielefeld Retired 2011-08-22 11:15:20 UTC
I see similar problems with .docx 

Sample document for "Bug 30713 - [FILESAFE]: Images only shown as placeholders in docx" shows Total Editing Time "0 Minutes", LibO 3.4.3RC1 "00:01:55", MAster "00:02:55". I did not find to check the XML <TotalTime> contents.
Comment 7 Björn Michaelsen 2011-12-23 13:25:28 UTC
Since all new unconfirmed bugs start in state UNCONFIRMED now and old unconfirmed bugs were moved to NEEDINFO with a explanatory comment, all bugs promoted above those bug states to NEW and later are automatically confirmed making the CONFIRMED whiteboard status redundant. Thus it will be removed.
Comment 8 QA Administrators 2015-02-19 15:44:27 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.0.3 or later): https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior

If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)

Thank you for your help!

-- The LibreOffice QA Team
This NEW Message was generated on: 2015-02-19
Comment 9 Buovjaga 2015-03-08 19:23:21 UTC
Confirmed.

Checked file - properties - Total editing time: 00:00:01

Win 7 Pro 64-bit, LibO Version: 4.4.1.2
Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432
Locale: fi_FI
Comment 10 Commit Notification 2015-04-30 12:20:26 UTC
Ravindra_Vidhate committed a patch related to this issue.
It has been pushed to "master":

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

tdf#38693: Document property TotalTime misinterpreted as seconds

It will be available in 5.0.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 11 Akshay Anand 2015-05-11 06:57:07 UTC
Verified on LO Windows Build ID : 

Version: 5.0.0.0.alpha1+
Build ID: 5984cc83fe756f7483d1ac582b8adbef5042be8b
TinderBox: Win-x86@42, Branch:master, Time: 2015-05-07_05:11:59
Locale: en-US (en_US)

Issue is fixed.