[GNC-dev] Significance of 18:59:00 in GnuCash 2.6.21 and altering of existing data

Geert Janssens geert.gnucash at kobaltwit.be
Sat May 2 04:19:15 EDT 2020

Hi Kevin,

The time changes have been done to deal with timezone issues. And I believe 2.6.21 may still 
not be doing it quite right. If I remember correctly the 3.x series received additional fixes.

I may have a few details wrong but this is the essence of it: gnucash used to poorly handle 
timezone data for its timestamps. That means that if the book was created in timezone A and 
then opened in timezone B, the dates would be interpreted differently. And depending in 
timezone A and B that could mean transactions could appear as being entered a day earlier or 
later. At some point I believe that for some users even the change in daylight saving time 
triggered the same issue.

So we set out to store time in a more neutral way. The idea is that setting the time to 10:59 UTC 
would be the safest. Only in the most extreme timezones this could possibly still cause an issue 
(though I think John even added checks to handle that).

The exact implementation of this idea has been modified several times as we discovered flaws 
but the idea is still there.

For 2.6.21 there was already an implementation of this, though I can't tell you offhand which 
iteration that would have been.

So what you see the 18:59 is most likely 10:59 compensated for your local timezone. Still not 
the ideal end solution. My current data file shows 10:59 +000, really meaning 10:59 UTC (I've 
used this with recent version of gnucash 3.x).

Note the more easy solution would have been to just drop time information and only use date 
information. That has been considered (and still is). At the time this bug was discovered, we 
decided to be conservative to avoid any unexpected breakage in case parts of the code did rely 
on the time information (spoiler alert, there were/may still be).



Op zaterdag 2 mei 2020 09:00:10 CEST schreef Kevin Buckley:
> Hi there,
> I appreciate that there may be some of you tempted to reply
> just to say "you're using an old version: upgrade" but just
> don't: you won't be addressing the issue, which exists betwee
> two versions of the 2.6 series.
> I've been happily using GnuCash 2.6.1 on an Ubuntu 14.04.6 LTS
> system for a good while now. (No, no, stop there, don't say it!)
> I recently decided to download the swathe of development DEBs
> that allowed me to do a CMMI of the 2.6.21 sources, and was very
> happy to see it compile without issue.
> I then took an existing dot-xac file (yes: been using GnuCash
> for that long!), copied it into a new directory, fired up the
> GnuCash 2.6.21, opened the copy, duplicated a single TXN, and
> saved the file and exited.
> I then compared the old (2.6.1) file with the new (2.6.21) file
> and whilst the new TXN was there, and nothing else of any note
> appeared to have been changed (a good thing), I noticed that EVERY
> value within the <ts:date> element of EVERY <trn:date-posted> element
> had had the time in that value changed, from 00:00:00 to 18:59:00.
> FWIW, the value in the <ts:date> element of the <trn:date-posted>
> element of the new (duplicated) TXN had that same 18:59:00 time.
> Furthermore, none of the times associated with the two files,
> or of the duplication of the TXN were set/done at 18:59:00, nor
> between 18:00 and 19:00, and not at 59 minutes past any hour.
> I appreciate that both times are, or appear to be, arbitrary,
> in that, by virture of all being the same, they are probably
> not used by GnuCash itself, but are just extracted from a time_t
> or similar structure that contains a date that gets created without
> a time and so needs something, rather, sometime.
> Was there a change then, between 2.6.1 and 2.6.21, that sees
> this arbitrary time changed/set and, if so, why 18:59:00?
> More importantly, even if GnuCash 2.6.21 had been designed to
> create any new <trn:date-posted><ts:date> values, or other
> time-insigniifcant "date-time" values, with the new arbitrary
> time, why would it alter the value in existing data?
> Was there something about 00:00:00 that GnuCash couldn't handle
> properly?
> I did think to grep the source tarball for the arbitrary time but it
> only seems to explicitly appear in some of the ChangeLogs, vis
> gnucash-2.6.21$ grep -r "18:59" *
> ChangeLog.2006:2006-02-26 18:59  codehelp
> ChangeLog.2006:2006-01-23 18:59  codehelp
> ChangeLog.2007:2007-10-26 18:59  cstim
> ChangeLog.2009:2009-11-08 18:59  plongstaff
> ChangeLog.2010:2010-08-03 18:59  cmarchi
> gnucash-2.6.21$
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

More information about the gnucash-devel mailing list