Summary:
Backports my upstream patch (https://phab.mercurial-scm.org/D2289)
Discovered by nemo on #mercurial freenode IRC, some months did not parse.
Reviewed By: DurhamG
Differential Revision: D12983571
fbshipit-source-id: b33227b0c986180966579afbb2b7c11fd48d275b
Summary: Also change the internal API so it no longer accepts the "heads" argument.
Reviewed By: ryanmce
Differential Revision: D6745865
fbshipit-source-id: 368742be49b192f7630421003552d0a10eb0b76d
d46a7814be5f refactored util.parsedate in order to raise ValueError instead
of Abort for using with ui.configwith. It causes several problems, putting
arbitrary bytes in ValueError can cause issues with Python 3. Moreover, we
added a function to convert ValueError exceptions back to Abort.
A better approach would be to make parsedate raises ParseError, removing
the convert function and update configwith to also catch ParseError.
The side-effect is that error message when giving an invalid date in CLI
change from:
abort: invalid date: 'foo bar'
to:
hg: parse error: invalid date: 'foo bar'
I'm not sure if it's an acceptable change, I found personally the error
message more clear but more verbose too.
The "normal" ISO date/time includes a T between date and time. It also
allows dropping the colons and seconds from the timespec. Add new
patterns for these forms as well as tests.
Prior to this patch, DST times where tested by specifying a custom TZ
environment variable that didn't defined DST transition times.
Due to a bug in glibc, the test fail on 32bits platforms that use timezone
files generated by zic from tzcode >= 2014c (glibc >= 2.20).
See https://sourceware.org/bugzilla/show_bug.cgi?id=19738
By defining explicit transition times for DST in the TZ environment variable,
the test is now independant to how the system guess those transition times.
Adding support to parsedate in util module to understand the more idiomatic
dates 'today' and 'yesterday'.
Added unified tests and docstring tests for added functionality.
The use of "{datetime}" was unfortunate since I as a user never knew
if I was expected to do
hg log -d '>{2011-04-01}'
or
hg log -d '>2011-04-01'
The word "datetime" is also confusing -- calling it a date it much
simpler.