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

[John Ralls]

On May 20, 2014, at 2:28 PM, Bob Gustafson <bobgus at rcn.com> wrote:

> 
> On 05/20/2014 10:11 AM, Geert Janssens wrote:
>> On Tuesday 20 May 2014 10:02:32 Bob Gustafson wrote:
>>> On 05/20/2014 09:41 AM, John Ralls wrote:
>>>> 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
>>> It is useful to have time and timezone on transactions that may
>>> involve a change of currency. Even within one country and currency
>>> (US) it is possible to have transactions occurring in different
>>> timezones.
>>> 
>> Please bear in mind that you can't enter such information in the current
>> version of gnucash either but it's recorded behind the scenes.
>> 
>> Until now I have only seen disadvantages of the fact that we keep track
>> of timezone and time information. Reports are off, scheduled
>> transactions trigger at the wrong time,...
>> 
>> Can you give an example where it would add value to keep timezone
>> information in GnuCash as it is now ?
>> 
>> Geert
> 
> I regularly look at transactions between the US and Germany. It is useful to track the time of the transaction in the US with the time of the deposit in Germany.
> 
> Synchronizing this with external events (currency exchange rates) it is possible to estimate how much the banks are charging above straight exchange rate.
> 
> Some days of the week are better than others.
> 

That’s nice, but you’re not doing it in GnuCash. If you think you are you’re fooling yourself.

Regards,
John Ralls