PeriodData's use of Int keys caused wrong results with periodic
reports involving dates outside the machine-specific limits of Int.
Those were:
64 bits: -25252734927764696-04-22..25252734927768413-06-12
32 bits: -5877752-05-08..5881469-05-27
16 bits: 1769-02-28..1948-08-04
8 bits: 1858-07-12..1859-03-24
32 bits is supported by MicroHS; 16 and 8 bits aren't supported by
any known haskell version, but that could change in future.
For example, on 64 bit machines we got:
25252734927768413-06-12 PeriodData's max date
(expenses) 1
25252734927768414-01-01 next year past PeriodData's max date
(expenses) 2
$ hledger reg -O csv --yearly
"txnidx","date","code","description","account","amount","total"
"0","-25252734927764696-11-10","","","expenses","1","1"
Now it uses Integer (like the time package), fixing the bug.
And benchmarking shows memory and time usage slightly improved
(surprisingly; tested with up to 500 subperiods, eg
hledger -f examples/10ktxns-1kaccts.journal reg -1 cur:A -D >/dev/null)
This allows us to guarantee that the report periods are well-formed and
don't contain errors (e.g. empty spans, spans not contiguous, spans not
a partition).
Note the underlying representation is now for disjoint spans, whereas
previously the end date of a span was equal to the start date of the
next span, and then was adjusted backwards one day when needed.
7 is no longer considered a scary shell character.
(This appears to have been harmless, used only for formatting the
balance assertion failure message.)
We no longer attempt to process timeclock entries in time order - that
was a wrong requirement, probably given by me, that can't work. Now
we just process them in parse order. This plus a little tweaking of
error checking fixes several ordering bugs with overlapping sessions
and also allows same-named overlapping sessions.
More cleanup will follow. More testing might show that --old-timeclock
is no longer needed.
Now we process entries in a more careful order: time, then parse
order, like journal format. This fixes the original issue and another
one mentioned at #2417.
The default timeclock parser (ie when not using --old-timeclock) has
the following changes, related to issues such as
[#2141], [#2365], [#2400], [#2417]:
- semicolon now always starts a comment; timeclock account names can't include semicolons
(though journal account names still can)
- clock-in and clock-out entries now have different syntax
- clock-ins now require an account name
- clock-outs now can have a comment and tags
- the doc has been rewritten, and now mentions the --old-timeclock flag
- lib: accountnamep and modifiedaccountnamep now take a flag to allow semicolons or not
In end-value reports with unspecified end date, a market price later
than the latest transaction can extend the default report end date and
valuation date. Now, only market prices on or before "today" can do this;
market price declarations dated in the future will be ignored.
Report span and valuation date calculations have been clarified.
Previously accounts were clipped in getPostings, however compound
balance reports re-use the output of getPostings for the different
subreports. This caused a problem when clipping erased the information
needed to determine the account type, as would be used by e.g.
incomestatement.
Add some extra tests for --count.
