gnucash master: A truly ancient bug, discovered with an Xcode-5.1 compiler warning.
jralls at ceridwen.us
Tue May 20 10:41:37 EDT 2014
On May 20, 2014, at 1:55 AM, Geert Janssens <janssens-geert at telenet.be> wrote:
> On Tuesday 20 May 2014 02:41:55 Mike Alexander wrote:
>> --On May 19, 2014 7:07:46 PM -0400 John Ralls
>> <jralls at code.gnucash.org>
>>> Updated via https://github.com/Gnucash/gnucash/commit/eabaee8e
>>> (commit) from https://github.com/Gnucash/gnucash/commit/6e62ce99
>>> commit eabaee8eb58c557743b8b1b476b4145b97eb9836
>>> Author: John Ralls <jralls at ceridwen.us>
>>> Date: Thu May 15 17:04:26 2014 -0700
>>> A truly ancient bug, discovered with an Xcode-5.1 compiler
>> Should this go on maint?
> While this is a bug I think it would not have had any influence in
> practise because the loop always breaks before the end of the string is
> reached for all known date formats.
Yeah, obviously that condition never mattered in practice because it would never be false.
> But I have backported the fix to maint anyway.
> And perhaps this is a good moment to point out that the routine itself
> is flawed and should be improved during the conversion to
> The issue with this routine is that it assumes that short date formats
> consist of only digits and a separator for all known locales. This is
> false. There are several oriental locales for which the short date
> format starts with a day-of-the-week field. For these locales the
> dateSeparator routine will return the first character of today's day of
> the week instead of the real separator. So every day of the week it
> would discover a different separator.
> This is strongly related to bug
> https://bugzilla.gnome.org/show_bug.cgi?id=497831 although the
> dateSeparator routine is only one part of the problem. The other part is
> the code that tries to guess an incompletely entered date in the
> register code. That part trips over the day-of-week part as well.
> Hopefully boost::datetime can help here.
I sure hope so. It has its own parsers and formatters that I hope will do everything we need.
One other thing I intend to do in that change is get rid of the entry-date-changes-with-timezone problem forever by making entry-date a plain date, no time component and no timezone. ISTM posted date should continue to be a full timestamp. Are there any other date-times where it's important that they should be one or the other?
More information about the gnucash-devel