Bug 65209 - FILEOPEN: MS Word document properties creation times etc. time zones not preserved/displayed
Summary: FILEOPEN: MS Word document properties creation times etc. time zones not pres...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
4.0.1.2 release
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: difficultyBeginner, easyHack, filter:doc, skillCpp
Depends on:
Blocks: DOC
  Show dependency treegraph
 
Reported: 2013-05-31 12:44 UTC by declan_moriarty
Modified: 2017-03-20 16:06 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Contains test time.doc, test timme MS Word properties.png and test time LibreOffice properties.png showing MS Word having correct time & LO having time 1 hour behind. (75.81 KB, application/zip)
2013-05-31 12:44 UTC, declan_moriarty
Details
Opened in Belgium (GMT + 1 + summer hour). Word for Mac left, LibreOffice right (127.12 KB, image/png)
2013-06-01 10:17 UTC, Jorendc
Details
Screenshot of test time file with LibreOffice 4.3.6.2 on Windows 8.1 (49.43 KB, image/png)
2015-03-07 18:38 UTC, Maarten Hoes
Details
LibreOffice Properties of test time.doc on OS X Mavericks 10.9.5 (73.80 KB, image/tiff)
2015-03-08 21:37 UTC, declan_moriarty
Details

Note You need to log in before you can comment on or make changes to this bug.
Description declan_moriarty 2013-05-31 12:44:31 UTC
Created attachment 80089 [details]
Contains test time.doc, test timme MS Word properties.png and test time LibreOffice properties.png showing MS Word having correct time & LO having time 1 hour behind.

Problem description: 

The Creation/Modified date timestamp displayed in Properties dialogue box shows the GMT time rather than the British Summer Time value for the particular time.  This only affects MS Word .doc files created on a Windows XP machine.  I am using a Windows PC to create proper .doc files and opening them in LibreOffice on an iMac.  Both machines are using British Summer Time and are synchronised to the internet using timeservers.

The MS Word documents generated by Word on the Windows box are one hour behind the correct time on the mac.  When opened in MS Word the same documents show the correct time.

This doesn't affect ODF documents created on the mac.

Using LibreOffice 4.0.0.3 on the PC produces ODF documents dated in LO properties as 16th April 2009 11:32 rather than 31st May 2013 12:32!  Note that the windows clock on the PC shows the correct time.


Steps to reproduce:
1. Create MS Word .doc document (using Word XP/2002) on a Windows XP PC set to BST or DST.
2. Transfere to mac running OS X Lion 10.7.3. (but any Mac OS X will probably make no difference) set to British Summer Time or Daylight Saving Time.
3. Note the file creation and modification dates in the Get Info or info pane for the file.
4. Open the file in LibreOffice and open the properties box.
5. The time in the properties box will be one hour less than the Creation/Modification times in Finder.

Current behaviour:  The creation/modification dates in LO Properties box is 1 hour < actual creation dates in Finder for file opened in LO created in MS Word on PC.

Expected behaviour:  Times in LO properties box match times in Finder and Windows explorer for file being opened.

              
Operating System: Mac OS X
Version: 4.0.1.2 release
Last worked in: 4.0.3.3 release
Comment 1 Jorendc 2013-06-01 10:17:58 UTC
Created attachment 80120 [details]
Opened in Belgium (GMT + 1 + summer hour). Word for Mac left, LibreOffice right
Comment 2 Jorendc 2013-06-01 10:20:50 UTC
Thanks for reporting!

I can confirm this behavior. Actually the mentioned time in LibreOffice is 13:15, the mentioned time in Word for Mac 14:15. I'm in time zone UTC+1 (+ 1 summer hour), so Word for Mac is right (12:15 + 2 hour shift = 14:15).

Tested using Mac OSX 10.8.3 with LibreOffice 4.1.0 beta 1.

kind regards,
Joren
Comment 3 Michael Stahl 2013-06-04 19:36:36 UTC
problem is that LO has never supported timezones in Document Properties.

but i believe it should be possible to do this properly with the
API changes to com.sun.star.util.DateTime for LO 4.1,
likely the Document Properties dialog in sfx2/source/dialog/dinfdlg.cxx
needs a little tweak to evaluate the timezone,
and/or the DocumentSummaryInformation
import/export in sfx2/source/doc/docinf.cxx needs to be taught
about timezones.

removing "regression" due to contradictory version information.
Comment 4 Lionel Elie Mamane 2013-06-05 04:29:31 UTC
(In reply to comment #3)
> problem is that LO has never supported timezones in Document Properties.
> but i believe it should be possible to do this properly with the
> API changes to com.sun.star.util.DateTime for LO 4.1,

Nothing happened wrt to timezone for 4.1. I originally planned to
add timezone support in some way, but it did not happen yet.

I expect that such a support is not necessary for this bug, though. That's how I would do it: If the timestamp (datetime) in the file is given "with timezone", it should be converted to UTC upon reading, stored in memory as UTC and converted to localtime for display.

When writing a file, we can just store the time always as UTC.

> likely the Document Properties dialog in sfx2/source/dialog/dinfdlg.cxx
> needs a little tweak to evaluate the timezone,
> and/or the DocumentSummaryInformation
> import/export in sfx2/source/doc/docinf.cxx needs to be taught
> about timezones.

Reading this file, sfx2/source/doc/oleprops.cxx and tools/source/datetime/datetime.cxx, from the comments the intention of the current design seems to be to convert to *local* time upon reading and then keep everything in local time. That can work too.

I don't see this conversion happening, though:

 - SfxOleFileTimeProperty::ImplLoad seems to read two "raw" 32-bit values
   from the file (the SvStream is the file I presume?)
 - and passes them to DateTime::CreateFromWin32FileDateTime
 - which possibly buggily (e.g. it ignores leap seconds) converts that
   to a ::DateTime

But possibly I'm missing it in some other place.

This seems to suggest that the file does not contain any timezone information after all... So the bug is in being *consistent* throughout internal LibreOffice code (either use localtime everywhere, or UTC everywhere), or in the conversion to localtime for display, or something like that.
Comment 5 Björn Michaelsen 2013-10-04 18:46:08 UTC
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.

see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Comment 6 Souvik Chakraborty 2015-03-07 16:51:30 UTC
Hi!

I'd like to help with this.

Will tweaking only the two mentioned files resolve this or do things need to be fixed throughout the libreoffice code?
Comment 7 Maarten Hoes 2015-03-07 18:38:19 UTC
Created attachment 113961 [details]
Screenshot of test time file with LibreOffice 4.3.6.2 on Windows 8.1

I cannot reproduce this with LibreOffice 4.3.6.2 on Windows 8.1.
Comment 8 Tomaz Vajngerl 2015-03-08 03:30:49 UTC
(In reply to Souvik Chakraborty from comment #6) 
> Will tweaking only the two mentioned files resolve this or do things need to
> be fixed throughout the libreoffice code?

You have the choice.. resolve the two mentioned files + every other people's file that are wrong (involves visiting every possible LibreOffice user) - HARD,
or fix the cause of this bug in the source code - EASY.
Comment 9 Souvik Chakraborty 2015-03-08 06:36:44 UTC
(In reply to Tomaz Vajngerl from comment #8)
> or fix the cause of this bug in the source code - EASY.

Okay. Let me see what can be done...
Comment 10 declan_moriarty 2015-03-08 21:37:55 UTC
Created attachment 113984 [details]
LibreOffice Properties of test time.doc on OS X Mavericks 10.9.5

I have produced a new attachment that shows I am able to reproduce this bug with the latest version of LO 4.4.0.3 on OS X Mavericks 10.9.5.
Comment 11 Maarten Hoes 2015-03-08 21:44:04 UTC
(In reply to Maarten Hoes from comment #7)
> Created attachment 113961 [details]
> Screenshot of test time file with LibreOffice 4.3.6.2 on Windows 8.1
> 
> I cannot reproduce this with LibreOffice 4.3.6.2 on Windows 8.1.


(In reply to declan_moriarty from comment #10)
> Created attachment 113984 [details]
> LibreOffice Properties of test time.doc on OS X Mavericks 10.9.5
> 
> I have produced a new attachment that shows I am able to reproduce this bug
> with the latest version of LO 4.4.0.3 on OS X Mavericks 10.9.5.

I guess this means that it is reproducible on OS X, but not Windows 8.1. Setting the OS from 'All' to 'MAC OS X'.
Comment 12 Robinson Tryon (qubit) 2015-12-13 10:00:13 UTC Comment hidden (obsolete)
Comment 13 Robinson Tryon (qubit) 2016-02-18 14:52:05 UTC Comment hidden (obsolete)
Comment 14 nassimedu92 2017-01-06 09:49:25 UTC
Hello, we try my friends and me to resolve this bug , I said we try lol. But I would have some explications about the SvStream file please
Comment 15 jani 2017-01-06 09:54:19 UTC
(In reply to nassimedu92 from comment #14)
> Hello, we try my friends and me to resolve this bug , I said we try lol. But
> I would have some explications about the SvStream file please


Why do you need SvStream, look at comment 3, it tell you which files to work with.
Comment 16 Yassine 2017-03-07 17:02:15 UTC
Changing status to "All operating systems", after successfully reproducing the bug on Ubuntu GNU/Linux.
Comment 17 Yassine 2017-03-07 18:05:01 UTC
Steps to reproduce under GNU/Linux:
 - Modify the timezone in your terminal with the following command: 
  sudo dpkg-reconfigure tzdata
 - Create a new file and save it to disk
 - Modify again the timezone and go to your normal timezone again with the same command: sudo dpkg-reconfigure tzdata
 - Open the newly created file, go to File -> Properties and then see that the timezone was not modified according to the change into the timezone.
Comment 18 Yassine 2017-03-20 16:02:18 UTC
While trying to find the place into the code where this issue is situated, we've found multiple files related to datetime

- /core/include/tools/datetime.hxx
- /tools/source/datetime/datetime.cxx
- /core/tools/source/datetime/datetimeutils.cxx
- /core/include/sfx2/dinfdlg.hxx
- /core/sfx2/source/doc/docinfo.cxx
- /core/sfx2/source/dialog/dinfdlg.cxx
- /core/sax/qa/cppunit/test_converter.cxx
- /core/unotools/source/misc/datetime.cxx
- /core/ucb/source/ucp/webdav-neon/DateTimeHelper.cxx
- /core/workdir/UnoApiHeadersTarget/offapi/normal/com/sun/star/util/DateTime.hpp

Could someone point us to the exact file where the date and time are saved into the properties of the document.

Could someone also explain the logic behind the file properties and how they are recorded/loaded while closing/opening a file. 

Thanks for the help
Comment 19 Lionel Elie Mamane 2017-03-20 16:06:20 UTC
(In reply to Yassine from comment #18)
> While trying to find the place into the code where this issue is situated,

> Could someone point us to the exact file where the date and time are saved
> into the properties of the document.

Please read comment 3 and comment 4.