import date trouble

[Jack]

On 2019.01.16 11:49, Thomas Baumgart wrote:
> On Mittwoch, 16. Januar 2019 16:08:01 CET Scott Lair wrote:
> > On Wed, 16 Jan 2019 14:21:20 +0100 Thomas Baumgart  
> <thb at net-bembel.de> wrote:
> > > On Mittwoch, 16. Januar 2019 14:15:26 CET Ralf Habacker wrote:
> > > > Am 15.01.19 um 22:30 schrieb Thomas Baumgart:

> > > > > The OFX specification is pretty clear at this point.
> > > > >
> > > > > Elements specified as type date or datetime and generally
> > > > > starting with the letters “DT” accept a fully formatted
> > > > > date-time-timezone string. For example,
> > > > > “19961005132200.124[-5:EST]” represents October 5, 1996, at  
> 1:22
> > > > > and 124 milliseconds p.m., in Eastern Standard Time. This is  
> the
> > > > > same as 6:22 p.m. Greenwich Mean Time (GMT). Date and datetime
> > > > > also accept values with fields omitted from the right. They
> > > > > assume the following defaults if a field is missing:
> > > > >
> > > > > YYYYMMDD						12:00 AM
> > > > > (the start of the day), GMT
> > > > > YYYYMMDDHHMMSS				GMT
> > > > > YYYYMMDDHHMMSS.XXX		GMT
> > > > >
> > > > > Your bank provides "<DTPOSTED>20181201000000" which represents
> > > > > midnight in GMT and since you are 5 hrs behing (EST) your  
> local
> > > > > time for this is 2018-11-30 19:00:00. Since KMyMoney only uses
> > > > > the date, that is what you see.
> > > >
> > > > According to http://www.ofx.net/downloads/OFX%202.2.pdf does the
> > > > server generating this statement seems to not follow the specs.
> > > >
> > > > "3.2.8.4 Time Zone Issues
> > > > ...
> > > > Although most transactions are not sensitive to the exact time,  
> they
> > > > often are sensitive to the date. In some cases, time zone errors
> > > > lead to actions occurring on a different date than intended by  
> the
> > > > customer. For this  reason, servers should always use a complete
> > > > local time plus GMT offset in any datetime values in a  
> response."
> > >
> > > Unless the server is located in the GMT timezone. Still, we have  
> the
> > > problem in case the user's timezone is located west of the  
> server's
> > > timezone and the timestamp provided is midnight. Then the date  
> will
> > > be off.
> > >
> >
> >
> > After reading your explanation Thomas, I thought that all  
> transactions
> > would be off one day. Either I'm -400 or -500 depending on daylight
> > saving time being in effect or not.  So I checked the transaction  
> the
> > month before dated 20181101000000 and according to KMyMoney it was
> > 20181101.  So for that transaction there was apparently no time  
> offset.
> > I checked a few more and noticed that after the Eastern timezone  
> went
> > off daylight savings (back to normal time) all the subsequent
> > transactions were back one day.
> >
> > So I manually changed the time on the 210181201000000 to
> > 20181201010000 in the ofx file. By adding one hour and re importing  
> the
> > file, the date was indeed correct. So the offset is only an hour and
> > only during winter months.
> >
> > Further, with debian buster and KMyMoney 4.8.1, I don't have the  
> date
> > problem - at least not with the December transaction that I have  
> been
> > focused on.  I do have the date problem with windows and debian
> > stretch.  If I can figure out why it works in debian buster and
> > duplicate that, I'd be good to go.
> 
> Can you tell us which versions of libofx are installed on these  
> systems? Could be, that this makes a difference.
> 
> > thanks for all your help.
> 
> You're welcome.
> 
> 
> Thomas
I also wonder if a Windows PC keeping the hardware clock at localtime,  
but Linux using UTC might be important here.  I'm not certain, but I  
don't think Windows changes the hardware clock when it switched to  
daylight savings, so that might play some role in this.  Unfortunately,  
that doesn't explain why one version of Debain shows the problem, but  
another does not.

Jack