[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).
Regards,
Geert
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