gnucash master: A truly ancient bug, discovered with an Xcode-5.1 compiler warning.

[John Ralls]

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>
>> wrote:
>>> Updated	 via  https://github.com/Gnucash/gnucash/commit/eabaee8e
>>> (commit) 	from  https://github.com/Gnucash/gnucash/commit/6e62ce99
>>> (commit)
>>> 
>>> 
>>> 
>>> 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
>>> 
>>> warning.
>> 
>> 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 
> boost::datetime.
> 
> 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?

Regards,
John Ralls