import date trouble

[Scott Lair]

On Wed, 16 Jan 2019 12:13:57 -0500
Jack <ostroffjh at users.sourceforge.net> wrote:

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

Versions of libofx:

Debian Stretch 
libofx6:amd64 1:0.9.10-2+deb9u1 

Debian Buster
libofx7:amd64 1:0.9.13-2

Windows - I'm not sure how to tell.

Wonder if its just a bug in the older version.  I force installed
libofx7 in Stretch, but I don't think its actually getting used
without changing library linkages etc... which is beyond my capability.

Just checked on the windows version and it has the same one hour offset
behaviour as Stretch.

Scott