This is used to define the beginning/ending ranges of the time period,
before it becomes fixed (by calling stabilize()) and then sets the
values of start and end.
date_specifier_t ::
This is like a plain date_t, except it knows what wasn't specified.
For example, if 2008/06 is parsed, it becomes date_specifier_t which
knows that no day was given. If you ask for the begin() date of the
specifier, it will be 2008/06/01; the end() date (which is
exclusive) will be 2008/07/01.
date_range_t ::
A date range is a range of two specifiers, either of which (but not
both) may be omitted. This makes it possible to represent
expressions like "from june to july", where no day or year is given.
The exact dates will be inferred by using the current year, and
fixing the range from YEAR/06/01 to YEAR/07/01. That is, the range
goes from the begin() of one date specifier to the begin() of the
other.
date_specifier_or_range_t ::
A variadic type that can be either a date_specifier_t or a
date_range_t. It's just a wrapper to represent the fact that ranges
can be implicit via specifiers (such as, "in june"), or explicit via
ranges ("since 2008").
This sets Ledger's notion of the "current time" to the given date. This
makes it possible to have stable output from budgeting and forecasting
reports, for the sake of baseline tests.
The code now uses Boost's input and output facets for times and dates.
This ensures completely consistency regarding timezones and times, and
fixes the regression test that was broken while I was away coding in
London (where it was GMT-0 and I didn't notice the difference between
local and GMT).
08-Aug-13. This allows for the account name to be one character wider, while
the century was never significant in people's minds, whereas the change in
months between two transactions sometimes is.
