import date trouble

[Thomas Baumgart]

Ralf,

On Donnerstag, 17. Januar 2019 13:53:18 CET Ralf Habacker wrote:

> Am 16.01.19 um 14:21 schrieb Thomas Baumgart:
> > 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
> ofx library seems not to be consistent in interpreting ofx datetimes.
> According to the above mentioned date patterns using real datetimes
> should give this:
> 
> 20181201           2018-12-01 01:00:00.000000 [CET]
> 20181201000000	   2018-12-01 01:00:00.000000 [CET]
> 20181201000000.000 2018-12-01 01:00:00.000000 [CET]
> 
> where importing the appended qfx file, which contains the dates
> describes above, with
> 
>    ofxdump test.qfx | grep Date | head -3plasma
> 
> results into different datetimes
> 
>    Date posted: Sat Dec  1 10:59:00 2018 CET
>    Date posted: Fri Nov 30 23:00:00 2018 CET
>    Date posted: Fri Nov 30 23:00:00 2018 CET
> 
> 
> The remaining 8 datetimes are expected to be
> 
> 20181201000000[GMT]	 2018-12-01 01:00:00.000000 [CET]
> 20181201000000.000[GMT]	 2018-12-01 01:00:00.000000 [CET]
> 20181201000000[-11]	 2018-12-01 12:00:00.000000 [CET]
> 20181201000000[-11:SST]	 2018-12-01 12:00:00.000000 [CET]
> 20181201000000[12]	 2018-11-30 13:00:00.000000 [CET]
> 20181201000000[12:MAGT]	 2018-11-30 13:00:00.000000 [CET]
> 20181201000000[+12]	 2018-11-30 13:00:00.000000 [CET]
> 20181201000000[+12:MAGT] 2018-11-30 13:00:00.000000 [CET]
> 
> and matches the related output from ofxdump:
> 
>   Date posted: Sat Dec  1 01:00:00 2018 CET
>   Date posted: Sat Dec  1 01:00:00 2018 CET
>   Date posted: Sat Dec  1 12:00:00 2018 CET
>   Date posted: Sat Dec  1 12:00:00 2018 CET
>   Date posted: Fri Nov 30 13:00:00 2018 CET
>   Date posted: Fri Nov 30 13:00:00 2018 CET
>   Date posted: Fri Nov 30 13:00:00 2018 CET
>   Date posted: Fri Nov 30 13:00:00 2018 CET
> 
> Am I missing something here, or does it look like a bug in libofx ?

Which version of libOFX are you using? There seems to be a difference in date handling between 0.9.12 and 0.9.13.


-- 

Regards

Thomas Baumgart

https://www.signal.org/       Signal, the better WhatsApp
-------------------------------------------------------------
It is better to remain silent and be thought a fool,
than to speak, and remove all doubt.
-------------------------------------------------------------
-------------- 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/20190117/91acbb49/attachment.sig>