A site devoted to discussing techniques that promote quality and ethical practices in software development.

Thursday, November 21, 2013

Caveats in using GnuCash - Time Zone dependent

For anyone that uses GnuCash to manage an account and then making this account available to someone in a different country (more correctly different time zone), you need to be aware of the treatment of transaction date in GnuCash as it can cause disagreement.

Or for traveller that takes their account on a trip and diligently changing the time zone on arrival of each location and then recording transaction en route. For example, if you travel from NYC and visit HK record a transaction, and return to NYC, GnuCash will render the transaction date for the HK transaction differently when viewed in NYC.

To understand this time zone dependency one needs to understand how GnuCash records the transaction date, which is stored in transactions.post_date.

GnuCash stores each transaction date (entered in local date) in UTC by converting the local date you enter taken as at 0000 hour using the system time zone and it does not stores the time zone information of the transaction date. But GnuCash always displays the transaction date in local date by conversion using the system time zone. If the transaction journals contain records recorded in different time zones, the user can be confused when viewing these transactions.

Recently I ran into a problem when I was reconstructing an account from a pile of statements from Hong Kong. I was entering the transactions, whose dates were clearly in Hong Kong Time zone using Brisbane Time zone (UTC+10) unaware of the conversion mechanism underneath.

When the GnuCash account was then shown in Hong Kong, after changing the system time zone to that of Hong Kong (UTC+8), all the transaction dates were one date behind even though the time zone difference was only 2 hours difference. How could this small change resulted in a 24 hours shift?

It turns out GnuCash drops the time when rendering the transaction date. Hence a transaction date of May 23, 2012 (at 0000) in Brisbane Time Zone recorded as 20120522140000 is converted to Hong Kong Time zone as 22/05/2012 2200 and displayed as 22/05/2012 after discarding the time.

Because GnuCash always uses 0000 hours on recording and then dropping the time after converting to local date/time, this can give an incorrect date, like a 24 hours shift.

For some other time zone difference the change does not yield any difference. It all depends on the shift.

This date treatment means:
1) that the database of GnuCash is tightly dependent on the time zone and one is ill-advised to change the system time zone. If you move domicile, you may have to create a brand new GnuCash database for that new time zone.

2) If dispatching the database to a different time zone, warn them conversion may alter the transaction date.

1 comment:

Anonymous said...

Yep, big inconvenient. I wonder how gnucash developers should have model transactions timing to avoid this mess.

Blog Archive