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