import date trouble

[Scott Lair]

On Thu, 17 Jan 2019 14:26:07 +0100
Thomas Baumgart <thb at net-bembel.de> wrote:

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

Interesting.

I tried this on ubuntu 17.10 which used libofx 0.9.12 and had the same
hour offset problem.

Wondering if there is any way to get the 0.9.13 version in windows.
Could I set up a dev environment on buster and create a windows
executable?

thanks all

Scott