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

Bob Gustafson bobgus at rcn.com
Tue May 20 19:42:00 EDT 2014


On 05/20/2014 05:16 PM, John Ralls wrote:
> 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
No, I am not doing it in GnuCash - but I wish I could.

My comment is to encourage any effort in the direction of time and 
timezone support and discourage attempts to close off that path.

As an example, here is a box of chocolates complete with timestamps..

viewspread13.27.csv:12345678	09/23/2013		-40.32		EINZUG 
AUSLANDSLASTSCHRIFT|9208|CHF      49,50KURS1,2276000|KURS VOM 20.09.13 
   MAFD|ZUERICH-FL AM19.09.13 15.50|	LINDT ZRH CHXR          CHE| 
10010000|	959566027|	EC-POSMAGNET6   GEB.EU 0,00|	002|	


More information about the gnucash-devel mailing list