date-posted to not be saved.
Check the stored GDate for being in the GncDateTime range as well
as the GDate range before returning it and check trans->date-posted
against INT64_MAX instead of 0 before changing it.
The first fix for this bug handled structs tm with ambiguous times.
This one fixes the GncDate constructor when the time is ambiguous
because it's in the DST-change hour, using the same add 3 hours,
construct the LDT, and subtract the 3 hours from the result.
The string constructor handles only simple-offset HH:MM timezones and so
is immune to the bug.
1. Modify dates-list definition
instead of either (list date0 date1 date) or
(list (list start0 end0 '())
(list start1 end1 '()) ...)
it now is a list-of-dates (list date0 date1 date2)
2. Pre-generate account-balances using dates-list.
account-balances-alist is an alist-of-balances
3. Use the pre-generated account-balance-alist instead of
calling (get-balance) to obtain balances. This
bypasses (get-balance) which calls a very expensive query-based
functions for every *account* and *date-interval*
This is neater. Split into 2 functions, both of which are useful
(monetaries-add . monetaries)
add different gnc-monetary objects into a gnc-commodity-collector
(monetaries+ . monetaries)
special case for above whereby all monetaries are expected to be in
one currency only -- convert gnc-commodity-collector to monetary
(gnc:account-get-balances-at-dates) is upgraded to
report-utilities. this function is slightly different to its
single-account counterpart because it does not retrieve subaccount
amounts.
I think this (gnc:account-get-balance-at-date) is flawed in sub-acct handling.
Consider account structure:
Assets [USD] - bal=$0
Bank [USD] - bal=$100
Broker [USD] - bal=$200
Cash [USD] - bal=$800
Funds [FUND] - bal=3 FUND @ $1000 each = $3000
- Calling (gnc:account-get-balance-at-date BANK TODAY #f) returns 100
- Calling (gnc:account-get-balance-at-date BROKER TODAY #f) returns 200
- Calling (gnc:account-get-balance-at-date BROKER TODAY #t) returns 1000
this is because although it counts all subaccounts bal $200 + $800 + 3FUND,
it retrieves the parent account commodity USD $1000 only.
It needs to be deprecated.
I think (gnc:account-get-balance-at-date) is flawed. It is actually
unused, so, it should be safe to remove. It needs to be deprecated.
Reports use xaccAccountGetBalanceAsOfDate instead, which does not
retrieve sub-acct balances.
I think this (gnc:account-get-balance-at-date) is flawed in sub-acct handling.
Consider account structure:
Assets [USD] - bal=$0
Bank [USD] - bal=$100
Broker [USD] - bal=$200
Cash [USD] - bal=$800
Funds [FUND] - bal=3 FUND @ $1000 each = $3000
- Calling (gnc:account-get-balance-at-date BANK TODAY #f) returns 100
- Calling (gnc:account-get-balance-at-date BROKER TODAY #f) returns 200
- Calling (gnc:account-get-balance-at-date BROKER TODAY #t) returns 1000
this is because although it counts all subaccounts bal $200 + $800 + 3FUND,
it retrieves the parent account commodity USD $1000 only.
