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-
[email protected]> wrote:
On Tuesday 20 May 2014 02:41:55 Mike Alexander wrote:
--On May 19, 2014 7:07:46 PM -0400 John Ralls
<[email protected]>
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 <[email protected]>
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.
Bob G
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
