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
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. kind regards, Joren
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.
(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
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.