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

[Kevin Buckley]

On Sat, 2 May 2020 at 16:19, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
>
> Hi Kevin,

Hello Geert,

thank you for your detailed reply.

> 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.

Assuming those additional fixes are identifiable, across the source
re-organisation,
the additional programang language and the adoption of the mighty boost, between
2.6 and 2.7/3.x, I may now look to backport those into my 2.6.21 sources.

Thanks for the pointer to that

> 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).

As someone who has tried to explain, to an "older member of the family",
what a 13-hour time difference implies for phone calls, I'm aware of many
of the issues. Thankfully, never needed to explain what a 13:45 difference
implied!

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

Not important, now that.you have explained the background.

I was thinking along TZ lines but the 59 posiibly suggested a case of
an "out by one" error, so it's good to know that that was the design.

What I have also seen, since initially posting, is that operating on the
file saved from 2.6.21, with the 2.6.1 GnuCash DOESN'T revert the
"10:59 UTC" changes and so the resulting XML file only contains a
diff for the second new (duplicated) TXN.


> 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).

Throwing away the time info sounds, on the surface, like a false
economy to me.

I'm aware of the occasional threads on the list that talk to the way
that TXNs get sorted in the ledger, and have always thought that
the ability to manipluate the time of a TXN, as opposed to playing
around with the "Num" field, affords more scope there, although
not a complete answer to the underlying issues.

Having said that, I'm sure that the accountants on the user list
would not be overly happy to hear talk of manipulating the data
at all!

I also did some programming, a long time ago now, against the
much missed Palm platform, utilising the pilot-link codebase, and
so have seen, first-hand the "timeless date-time" approach in the
wild. For the price of adding 8 extra characters per time string to
the readable representations of a time_t in the XML, I think you
get a decent "return on your investment".

Once again, thanks for the detailed explantion, and to all the devs,
for GnuCash,
Kevin