gnucash is confused by timezone changes

Bug #365065 reported by Martin Pool on 2009-04-22
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
GnuCash
In Progress
High
gnucash (Debian)
Confirmed
Unknown
gnucash (Ubuntu)
Medium
Unassigned

Bug Description

Binary package hint: gnucash

When I move my laptop eg from Sydney to London timezone, gnucash behaves poorly.

The user model is that transactions are done on a particular day; for example I pay my rent on the first day of each month. When creating a transaction in the ledger or through a recurring transaction, one can only choose a date for it to occur, not a time, and I doubt that tracking the time would be very useful.

However, it looks like gnucash internally stores the transaction as a timestamp, and displays them in the local time. So after moving to London, the rent payments appear to have been done on the last day of the previous month, and if I enter transactions in London they'll appear against the wrong day when I return home.

As a workaround you can set TZ before running gnucash.

There's some discussion of it here:

http://<email address hidden>/msg03494.html

On Sat, Nov 02, 2002 at 09:24:44AM -0600, John Goerzen wrote:
> Package: gnucash
> Version: 1.6.8-3
> Severity: important
>
> Recently I moved from one US state to another, and as a result, my timezone
> changed to one hour earlier.
>
> After making this adjustment on my computer, every single date in every
> gnucash register was made one day earlier. For instance, November 8 became
> November 7.

Upstream reports that dates are stored as being 00:00:01 in LOCAL time
which is obviously causing your problem. A bug is being filed upstream.

--
James (Jay) Treacy
<email address hidden>

Tags: upstream

Believing you, I tag this to help the maintainer.

tag 167453 upstream
thanks

Hi,

I can't find this bug upstream (I'd like to, so I can mark this bug as
forwarded and/or query the gnucash maintainers about it). Can anyone
find it?

Joachim
--
Joachim "nomeata" Breitner
  e-Mail: <email address hidden> | Homepage: http://www.joachim-breitner.de
  JID: <email address hidden> | GPG-Keyid: 4743206C | ICQ#: 74513189
  Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?>+ V?
            PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+>* h! z?
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html

On Sat, Nov 02, 2002 at 09:24:44AM -0600, John Goerzen wrote:
>
> Recently I moved from one US state to another, and as a result, my timezone
> changed to one hour earlier.
>
> After making this adjustment on my computer, every single date in every
> gnucash register was made one day earlier. For instance, November 8 became
> November 7.

This is really a problem with the data you imported as it did not
specify the timezone of the transaction (or gave erroneous data).
Older versions of ofx followed the spec and assumed GMT whenever there
was ambiguity. Under some circumstances this led to the problem you
have.

A long discussion upstream resulted in a compromise that follows
the spec as closely as possible while minimizing the chance of your
problem happening (IIRC, you'd have to import a bad file and then
move to one of the little used timezones in the Pacific).

You should contact the institution that is generating data that doesn't
follow the OFX spec and get them to fix the it.

As far as correcting the problem for your existing transactions,
upstream suggested only one fix: change the date for all affected
transactions to the correct date. Any future changes to your timezone
should not affect the date of the transaction.

I consider this bug closed. Please test the above solution and tell
me how it went. I won't close the bug until you respond (I'll give a few
weeks). In the meantime the severity of the bug will be downgraded to
normal.

--
James (Jay) Treacy
<email address hidden>

severity 167453 normal
stop

--
James (Jay) Treacy
<email address hidden>

On Wed, Oct 15, 2003 at 11:21:29PM -0400, James A. Treacy wrote:
> This is really a problem with the data you imported as it did not
> specify the timezone of the transaction (or gave erroneous data).

None of the data was imported; it was all keyed into Gnucash manually. That
seems to unfortunately render the rest of your message irrelevant; is that
the case, or am I misunderstanding something?

On Wed, Oct 15, 2003 at 10:36:43PM -0500, John Goerzen wrote:
> On Wed, Oct 15, 2003 at 11:21:29PM -0400, James A. Treacy wrote:
> > This is really a problem with the data you imported as it did not
> > specify the timezone of the transaction (or gave erroneous data).
>
> None of the data was imported; it was all keyed into Gnucash manually. That
> seems to unfortunately render the rest of your message irrelevant; is that
> the case, or am I misunderstanding something?

Life is never easy.

Can you check to see that this still occurs with 1.8.7?

--
James (Jay) Treacy
<email address hidden>

On Thu, Oct 16, 2003 at 12:40:47AM -0400, James A. Treacy wrote:
> On Wed, Oct 15, 2003 at 10:36:43PM -0500, John Goerzen wrote:
> > None of the data was imported; it was all keyed into Gnucash manually. That
> > seems to unfortunately render the rest of your message irrelevant; is that
> > the case, or am I misunderstanding something?
>
> Life is never easy.
>
> Can you check to see that this still occurs with 1.8.7?

Yes, it does. My timezone is US/Central. I ran TZ=US/Pacific gnucash &.
Sure enough, all dates went one day earlier.

-- John

tags 167453 + confirmed
tags 167453 + upstream
thanks

severity 167453 important
thanks

reopen 167453
reopen 247831
tags 167453 + sarge,woody
tags 247831 + sarge,woody
thanks

tags 167453 - sarge,woody
tags 247831 - sarge,woody
reopen 120933
repoen 190118
tags 120933 + sarge,woody
tags 190118 + sarge,woody
thanks

#
# bts-link upstream status pull for source package gnucash
# see http://lists.debian.org/debian-devel-announce/2006/05/msg00001.html
#

user <email address hidden>

# remote status report for #167453
# * http://bugzilla.gnome.org/show_bug.cgi?id=137017
# * remote status changed: (?) -> NEW
forwarded 167453 http://bugzilla.gnome.org/show_bug.cgi?id=137017
usertags 167453 + status-NEW

# remote status report for #248406
# * http://bugzilla.gnome.org/show_bug.cgi?id=143720
# * remote status changed: (?) -> RESOLVED
# * remote resolution changed: (?) -> RESOLVED
# * closed upstream
forwarded 248406 http://bugzilla.gnome.org/show_bug.cgi?id=143720
tags 248406 + fixed-upstream
usertags 248406 + status-RESOLVED resolution-FIXED

thanks

# Automatically generated email from bts, devscripts version 2.10.8
found 167453 2.2.1-1

Martin Pool (mbp) wrote :

Binary package hint: gnucash

When I move my laptop eg from Sydney to London timezone, gnucash behaves poorly.

The user model is that transactions are done on a particular day; for example I pay my rent on the first day of each month. When creating a transaction in the ledger or through a recurring transaction, one can only choose a date for it to occur, not a time, and I doubt that tracking the time would be very useful.

However, it looks like gnucash internally stores the transaction as a timestamp, and displays them in the local time. So after moving to London, the rent payments appear to have been done on the last day of the previous month, and if I enter transactions in London they'll appear against the wrong day when I return home.

As a workaround you can set TZ before running gnucash.

There's some discussion of it here:

http://<email address hidden>/msg03494.html

Changed in gnucash:
status: Unknown → Confirmed
Changed in gnucash (Debian):
status: Unknown → Confirmed
Rolf Leggewie (r0lf) on 2009-04-22
Changed in gnucash (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed
Changed in gnucash:
importance: Unknown → High
Changed in gnucash:
status: Confirmed → In Progress
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.