Fix changelog timezone parsing
I noticed that in the reimport of gpsd, cgit reported
2020-03-18 16:52:59 +0100
...whereas the changelog timestamp said
Wed, 18 Mar 2020 15:52:59 +0100
...so there appeared to be something wrong with the parsing.
It turns out that the timezone component in the changelog was being
ignored because Python's time.strptime() is defined to ignore it. We
must use datetime.strptime() instead. The parsing is therefore entirely
adjusted to use only a datetime object.
This wasn't being caught in tests because the expected test value was
wrong - presumably calculated with the same mistake.
I have verified that, based on the date string given in
gitubuntu/changelog_tests/test_date{1,2}, using:
date +%s -d "Mon, 12 May 2016 08:14:34 -0700"
...does report the value of 1463066074, so all tests are adjusted
accordingly. I have also verified that the above command does mutate the
answer if the timezone is mutated, so it does appear to be correctly
timezone-aware.
While there still a risk that I have calculated the expected value
wrong, hopefully the above test migitates this sufficiently. We do
already have adequate test coverage that will prevent regressions in
Changelog.git_authorship(); the problem was that the expected values in
those tests were wrong and this is now fixed.
Preserve MPs on reimport
When reimporting, instead of deleting a git repository before repushing
it, we can force push all our new refs and ensure that refs not being
pushed get deleted using --prune. This creates the same effect but
allows us to preserve old merge proposals.
There is a possibility that some configuration in the git repository
will be left behind from a previous import. However all configuration
(eg. the HEAD pointer) is reset by the importer on every run, so
everything that the importer touches will get fixed. Anything else can
be considered out of scope for --reimport to achieve.
The default repository for the source package will therefore not be
reset; if it was set to the old repository, it will continue to point to
the "new" one. This is actually what we want, so is fine.
