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.
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 18.104.22.168 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: 22.214.171.124 release
Last worked in: 126.96.36.199 release
Created attachment 80120 [details]
Opened in Belgium (GMT + 1 + summer hour). Word for Mac left, LibreOffice right
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.
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
removing "regression" due to contradictory version information.
(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.
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
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?
Created attachment 113961 [details]
Screenshot of test time file with LibreOffice 188.8.131.52 on Windows 8.1
I cannot reproduce this with LibreOffice 184.108.40.206 on Windows 8.1.
(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.
(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...
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 220.127.116.11 on OS X Mavericks 10.9.5.
(In reply to Maarten Hoes from comment #7)
> Created attachment 113961 [details]
> Screenshot of test time file with LibreOffice 18.104.22.168 on Windows 8.1
> I cannot reproduce this with LibreOffice 22.214.171.124 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 126.96.36.199 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'.
Migrating Whiteboard tags to Keywords: (easyHack, difficultyBeginner, skillCpp)
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC)
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
(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.
Changing status to "All operating systems", after successfully reproducing the bug on Ubuntu GNU/Linux.
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.
While trying to find the place into the code where this issue is situated, we've found multiple files related to datetime
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
(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.
follow up to comment #3 and comment #4:
some reading reveals that there is exactly 1 timezone in MSO binary files: the type FILETIME is always UTC, as specified in [MS-DTYP] https://msdn.microsoft.com/en-us/library/cc230273.aspx "2.3.3 FILETIME".
hence the import code in oleprops.cxx should set the util::DateTime value to UTC, and the SfxDocumentInfoDialog may need to either display an UTC marker or convert to local time.