import date trouble

[Thomas Baumgart]

Scott,

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

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


-- 

Regards

Thomas Baumgart

https://www.signal.org/       Signal, the better WhatsApp
-------------------------------------------------------------
Got Mole problems? Call Avogadro at 6.02 x 10^23.
-------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 868 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kmymoney/attachments/20190116/907e2633/attachment.sig>