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

John Ralls jralls at
Tue May 20 13:00:44 EDT 2014

On 20 May 2014, at 08:02, Bob Gustafson <bobgus at> wrote:

> On 05/20/2014 09:41 AM, John Ralls wrote:
>> On May 20, 2014, at 1:55 AM, Geert Janssens <janssens-geert at> 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>
>>>> wrote:
>>>>> Updated	 via
>>>>> (commit) 	from
>>>>> (commit)
>>>>> commit eabaee8eb58c557743b8b1b476b4145b97eb9836
>>>>> Author: John Ralls <jralls at>
>>>>> 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
>>> 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.
> I would vote to retain the possibility of entering time and timezone, even if the user chooses to ignore those fields.
> The multiple currency, global nature of Gnucash is one of its attractive features. Time is important.

That's the problem: There is no ability to enter the time or timezone. The time is set to 00:00 on the current date in localtime and converted to Zulu (aka UTC or GMT) for storage. If the file is then opened in a different timezone, the time of the transaction is changed to that localtime, and if it's "later" TZ, e.g. if the transaction was entered in US Eastern Time and then the file is opened in US Pacific Time, the transaction entry date changes. This has been the source of constant complaints.

As for exchange rates, the entry date/time has absolutely no effect. The actual exchange rate for book-keeping purposes is determined by the ratio of the amount and value fields in the "other currency/commodity", i.e. other than the transaction currency, split. That's set when you create or edit the transaction. Asset valuation in some reports when calculated with "nearest in time" prices from the pricedb might be affected in the rare case where there is more than one price on a particular day, but the effect will be small unless there was a really major pricing event as when a company releases bad news that tanks the stock price, but because the time is already artificially set to midnight local time there's no change by just using a date with no time.

John Ralls

More information about the gnucash-devel mailing list