Dates are hard. How can users know if we parsed the date right? They
don't know we warn when we fail, but even if they would, humans and
machines tend to differ in the way they parse dates, as those are
necessarily ambiguous and context-dependent. Giving the user feedback
ensures they can validate the date.

We don't enforce a date style, so presumably Python will pick the
right thing from the user based on locale, which should help the user
as well.

Downside is there more noise in the output.

This makes it more useful out of the box and does not flood the
terminal.

In that standard, the presence of the NO_COLOR environment variable
disables color escape sequences in the output.

See http://no-color.org/ for details.

git push includes tags in later version and git-buildpackage was
renamed to gbp.

we also forgot to include the Debian package upload.

Fix typo in README.rst

See merge request !2

We forgot to mention the stars/underscore feature and the default
color config.

We do not need to know which user triggered the error, which is
included by default in logging library.

move the overtime reference to the credits part, it is not very
useful. also in fix formatting and cross-reference another issue.

Finally acquiese to pabs' arguments that a piped program shouldn't
produce escape sequences. My argument was that --no-colors could be
used to fix the behavior, but it's true that the proper behavior by
default would be better, and we can always force colors with --colors
thanks to my shiny NegateAction (I *KNEW* this would be useful
eventually).

We now look for uppercase and spaces replaced with underscores

We just wrote the damn thing by hand instead of adding yet another
crazy build dependency. It's annoying as hell, but at least it's done
only once.

Partial fix for #891379: ship the readme, contributing instructions
and code of conduct with the package to satisfy users with *some*
documentation.

Even if we do not have colors, we can still outline with
*something*. We use the "star" character (*) instead of "bold" (or
really, any "attribute") and "underline" (_) for any color.

Thanks to Adam Borowski for the suggestion

The SingleTable formatter uses [box drawing characters][1] (e.g. `Esc
( 0`) whereas the DoubleTable formatter "automatically converts CP437
double-line box characters to Unicode and displays that instead",
which is what we are actually looking for here.

There can apparently be gaps between lines in "POSIX", but the display
looks fine in urxvt and gnome-terminal with the default "Monospace"
font.

 [1]: https://en.wikipedia.org/wiki/Box-drawing_character