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

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?

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 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 4.4.0.3 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 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'.

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

- /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

(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.

(In reply to Rakshita Varadarajan from comment #22)
> Hello! Can I work on this issue? I just reproduced the error in Ubuntu 20.04.

As you can see from the comments and status, nobody is working on this as of now.

(In reply to Buovjaga from comment #23)
> (In reply to Rakshita Varadarajan from comment #22)
> > Hello! Can I work on this issue? I just reproduced the error in Ubuntu 20.04.
> 
> As you can see from the comments and status, nobody is working on this as of
> now.

Okay great, I'll get started

(In reply to Michael Stahl (allotropia) from comment #20)
> 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.

Hello,

I tried doing this, ie, changing util::DateTime value to UTC, but it is not working and I am stuck.
The 3 main changes in oleprops.cxx:

SfxOleFileTimeProperty::SfxOleFileTimeProperty( sal_Int32 nPropId, const util::DateTime& rDateTime ) :
    SfxOlePropertyBase( nPropId, PROPTYPE_FILETIME )
{   
    DateTime trialDateTime(rDateTime);
    trialDateTime.ConvertToUTC();
    maDateTime.Year    = trialDateTime.GetYear();
    maDateTime.Month   = trialDateTime.GetMonth();
    maDateTime.Day     = trialDateTime.GetDay();
    maDateTime.Hours   = trialDateTime.GetHour();
    maDateTime.Minutes = trialDateTime.GetMin();
    maDateTime.Seconds = trialDateTime.GetSec();
    maDateTime.NanoSeconds = trialDateTime.GetNanoSec();
    maDateTime.IsUTC   = true;
}

void SfxOleFileTimeProperty::ImplLoad( SvStream& rStrm )
{
    sal_uInt32 nLower(0), nUpper(0);
    rStrm.ReadUInt32( nLower ).ReadUInt32( nUpper );
    ::DateTime aDateTime = DateTime::CreateFromWin32FileDateTime( nLower, nUpper );
    // note: editing duration is stored as offset to TIMESTAMP_INVALID_DATETIME
    //       of course we should not convert the time zone of a duration!
    // heuristic to detect editing durations (which we assume to be < 1 year):
    // check only the year, not the entire date
    if ( aDateTime.GetYear() != TIMESTAMP_INVALID_DATETIME.GetYear() )
        aDateTime.ConvertToUTC();
    maDateTime.Year    = aDateTime.GetYear();
    maDateTime.Month   = aDateTime.GetMonth();
    maDateTime.Day     = aDateTime.GetDay();
    maDateTime.Hours   = aDateTime.GetHour();
    maDateTime.Minutes = aDateTime.GetMin();
    maDateTime.Seconds = aDateTime.GetSec();
    maDateTime.NanoSeconds = aDateTime.GetNanoSec();
    maDateTime.IsUTC   = true;
}

void SfxOleSection::SetFileTimeValue( sal_Int32 nPropId, const util::DateTime& rValue )
{
    if ( rValue.Year == 0 || rValue.Month == 0 || rValue.Day == 0 )
        SetProperty( std::make_shared<SfxOleFileTimeProperty>( nPropId, TIMESTAMP_INVALID_UTILDATETIME ) );
    else{
        DateTime trialDateTime(rValue);
    trialDateTime.ConvertToUTC();
    util::DateTime rVal;
    rVal.Year    = trialDateTime.GetYear();
    rVal.Month   = trialDateTime.GetMonth();
    rVal.Day     = trialDateTime.GetDay();
    rVal.Hours   = trialDateTime.GetHour();
    rVal.Minutes = trialDateTime.GetMin();
    rVal.Seconds = trialDateTime.GetSec();
    rVal.NanoSeconds = trialDateTime.GetNanoSec();
    rVal.IsUTC   = true;
        SetProperty( std::make_shared<SfxOleFileTimeProperty>( nPropId, rVal ) );
    }
}

However, it is still not working.

On adding ConvertToUTC() in SfxDocumentInfoDialog, it shows the proper UTC time, however fundamentally it is still being saved wrong to the file. Is there any guidance you can provide here? I am trying really hard to see what I may be missing

hi Rakshita,

i wonder, looking at the SfxOleFileTimeProperty methods, how many times is ConvertToUTC called when storing such a property?

(In reply to Michael Stahl (allotropia) from comment #26)
> hi Rakshita,
> 
> i wonder, looking at the SfxOleFileTimeProperty methods, how many times is
> ConvertToUTC called when storing such a property?

AIn the current repo code, it is being called only once in the ImplSave method
 
The constructor SfxOleFileTimeProperty( sal_Int32 nPropId, const util::DateTime& rDateTime ) directly initializes the private variable of util::DateTime to this value got in the constructor, however this time is local time so I changed the code to ConvertToUTC and then initialized the util::DateTime maDateTime variable. 
Another change I did was in the method ImplLoad, it initially converted everything to local time and fed values to maDateTime, so once more I used ConvertToUTC 

I feel I may be missing something, but I am still making changes and trying my best

(In reply to Rakshita Varadarajan from comment #27)

util::DateTime has an IsUTC flag, right? so i don't understand the point of unconditionally converting a util::DateTime from local time to UTC.

also, can it happen that ImplSave and SetFileTimeValue are both called on storing the file? how many conversions would that be?

(In reply to Michael Stahl (allotropia) from comment #28)
> (In reply to Rakshita Varadarajan from comment #27)
> 
> util::DateTime has an IsUTC flag, right? so i don't understand the point of
> unconditionally converting a util::DateTime from local time to UTC.
> 
> also, can it happen that ImplSave and SetFileTimeValue are both called on
> storing the file? how many conversions would that be?

Yes my bad, I realized it last night and added the condition that when IsUTC flag is false, it converts from local to UTC.

Yes, right? They will both be called, and it will be called twice then. 
So I changed the code and removed the converting to UTC in SetFileTimeValue, instead kept it in ImplSave itself. The code still fails. 

I had a doubt: ideally, if there is a static value fed to maDateTime in ImplSave, then the DateTime value that should be shown in the dialogue box should be that static value right? however, it is showing instead the local time of storing the file.
Is it possible there is something else interfering with this process?

Dear  Rakshita Varadarajan,
This bug has been in ASSIGNED status for more than 3 months without any
activity. Resetting it to NEW.
Please assign it back to yourself if you're still working on this.