import date trouble

[Scott Lair]

On Wed, 16 Jan 2019 14:21:20 +0100
Thomas Baumgart <thb at net-bembel.de> wrote:

> Hi,
> 
> 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.

thanks for all your help.