[ libofx-Bugs-778615 ] NZ date (GMT +12) is 1 day out.

Bugs item #778615, was opened at 2003-07-27 17:28
Message generated for change (Comment added) made by benoitg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=496353&aid=778615&group_id=61170

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: John Zoetebier (johnzoet)
>Assigned to: Benoit Grégoire (benoitg)
Summary: NZ date (GMT +12) is 1 day out.

Initial Comment:
Local time is NZDT : GMT +12

When I import an OFX file the date imported is 1 day higher than the 

date in the OX file.



For example:

<DTPOSTED>20030721

This shows up in GnuCash as 21/ 7/2003

It should be: 20/ 7/2003



From the feedback from GnuCash I read:

==>

To solve this problem (since usually a time error is relatively

unimportant, but date error is), I decided to use the following 

behavior:

  -If no specific time is given in the file (date only), the

transaction is assumed to have occurred 12h00 (noon) GMT.  This 

way,

we will never

change the date, since in any event we didn't know when in the day 

the

transaction occurred in the first place.

==>



As NZ day time is GMT + 12 it immediately follows that NZ date will be 

changed to next day.

I suggest to change specs to:

  -If no specific time is given in the file (date only), the

transaction is assumed to have occurred 11:59 GMT.



This spec will work in NZ as well.





----------------------------------------------------------------------

>Comment By: Benoit Grégoire (benoitg)
Date: 2003-09-12 00:13

Message:
Logged In: YES 
user_id=597400

Fixed in 0.6.5.  The policy is now: 



DEVIATION FROM THE SPECS : The OFX specifications (both

version 1.6 and 2.02) state that a client should assume that

if the server returns a date without à specific time, we

assume it means 0h00 GMT. As such, when we apply the local

timezone and for example you are in the EST timezone, we

will remove 5h, and the transaction will have occurred on

the prior day! This is probably not what the bank intended

(and will lead to systematic errors), but the spec is quite

explicit in this respect (Ref: OFX 2.01 spec pp. 66-68)



To solve this problem (since usually a time error is

relatively unimportant, but date error is), and to avoid

problems in Australia caused by the behaviour in libofx up

to 0.6.4, it was decided starting with 0.6.5 to use the

following behavior:



-No specific time is given in the file (date only):

Considering that most banks seem to be sending dates in this

format represented as local time (not compliant with the

specs), the transaction is assumed to have occurred 11h59

(just before noon) LOCAL TIME. This way, we should never

change the date, since you'd have to travel in a timezone at

least 11 hours backwards or 13 hours forward from your own

to introduce mistakes. However, if you are in timezone +13

or +14, and your bank meant the data to be interpreted by

the spec, you will get the wrong date. We hope that banks in

those timezone will either represent in local time like

most, or specify the timezone properly.



-No timezone is specified, but exact time is, the same

behavior is mostly used, as many banks just append zeros

instead of using the short notation. However, the time

specified is used, even if 0 (midnight).



-When a timezone is specified, it is always used to properly

convert in local time, following the spec.

----------------------------------------------------------------------

Comment By: Benoit Grégoire (benoitg)
Date: 2003-07-27 18:12

Message:
Logged In: YES 
user_id=597400

This will not work for everyone, as there are cities located

from -11 to +14.  (A timezone is defined for -12, but I

couldn't find any place that uses it).



So it seems that the only solution is to change the

conversion policy FROM:

   -If no specific time is given in the file (date only),

the transaction is assumed to have occurred 12h00 (noon)

GMT.  This way, we will never change the date, since in any

event we didn't know when in the day the transaction

occurred in the first place. We assume that if the

transaction was timezone sensitive, a proper time, with

timezone would have been specified.

  -If no timezone is specified, but exact time is, the

timezone is assumed to be GMT, following the spec.

  -If a timezone is specified, it is used to properly

convert in local time.



TO:

  -Considering that most banks seem to be sendind dates in

this format represented as local time (not compliant with

the specs), if no specific time is given in the file (date

only), the transaction is assumed to have occurred 11h59

(just befor noon) LOCAL TIME.  This way, we should never

change the date, since you'd have to travel in a timezone at

least 11 hours backwards or 13 hours forward from your own

to introduce mistakes.  However, if you are in timezone +13

or +14, and your bank meant the deta to be interpreted by

the spec, you will get the wrong date.  We hope that banks

in those timezone will either represent in local time like

most, or specify the timezone properly.

  -If no timezone is specified, but exact time is, the

timezone is assumed to be GMT, following the spec.

  -If a timezone is specified, it is used to properly

convert in local time.



What do you think?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=496353&aid=778615&group_id=61170


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf