As a last test, add the following, which will help determining which
part of qof_print_date_buff is playing up.
I think it should output ('locale 4)...
modified gnucash/report/standard-reports/transaction.scm
(add-if (column-uses? 'date)
(vector (_
Thank you
This confirms my suspicion that guile is not the culprit.
Excerpt
[pass] line:647, test: dual amount column, with original currency headers
[pass] line:651, test: dual amount column, grand totals available
[pass] line:654, test: dual amount column, first transaction correct
d0.1102
On 1/20/19 8:07 PM, Christopher Lam wrote:
> There's no reason why the dates can't be changed.
>
> The reason dates straggling 1.1.1970 was chosen was because 1.1.1970
> corresponds to time 0 in time64, and I felt that having a few negative
> time64 numbers would be interesting to test sorting.
>
On 1/20/19 8:07 PM, Christopher Lam wrote:
> There's no reason why the dates can't be changed.
>
> The reason dates straggling 1.1.1970 was chosen was because 1.1.1970
> corresponds to time 0 in time64, and I felt that having a few negative
> time64 numbers would be interesting to test sorting.
>
There's no reason why the dates can't be changed.
The reason dates straggling 1.1.1970 was chosen was because 1.1.1970
corresponds to time 0 in time64, and I felt that having a few negative
time64 numbers would be interesting to test sorting.
However this is a weird weirdness -- the test
> On Jan 20, 2019, at 1:24 PM, Stephen M. Butler wrote:
>
> Started clean this morning by recloning the git repository. Made much
> further progress but ended up with some test failures. Here are my steps:
>
> 1. sudo rm -rf gnucash
>
> 2. git clone https://github.com/Gnucash/gnucash
>
Started clean this morning by recloning the git repository. Made much
further progress but ended up with some test failures. Here are my steps:
1. sudo rm -rf gnucash
2. git clone https://github.com/Gnucash/gnucash
3. cd gnucash
4. git checkout -b debian
5. cp -r ../debian .
