Accept PO files with unchanged revision dates

Looking at the code, this seems to be already happening. Need to investigate why do some PO files still exhibit stale PO-Revision-Date problem then when it appears they have exactly the same dates.

As requested, here are a the emails that I got about this for gnome-power-manager:

------------------ 8< ----------------------
To: <email address hidden>
From: <email address hidden>
Subject: Import problem - Latvian (lv) - gnome-power-manager in Ubuntu Jaunty
        package "gnome-power-manager"
Date: Wed, 18 Mar 2009 21:54:17 -0000
Reply-To: <email address hidden>

Hello Martin Pitt,

On 2009-03-03 15:03+0000 (15 days 6 hours 51 minutes ago), you uploaded
a file with Latvian (lv) translations for gnome-power-manager in Ubuntu
Jaunty package "gnome-power-manager" in Launchpad.

We were unable to import your translations because you did not update
the time stamp in its header to state when you added your translations.

To fix this problem, please upload the file again, but with the 'PO-
Revision-Date' field updated.

For your convenience, you can get the file you uploaded at:
http://launchpadlibrarian.net/24063113/lv.po

Thank you,

The Launchpad team
------------------ 8< ----------------------

Exactly the same template, but for:

English (Canada) (en_CA): http://launchpadlibrarian.net/24063098/en_CA.po
Brazilian Portuguese (pt_BR): http://launchpadlibrarian.net/24063133/pt_BR.po
Romanian (ro): http://launchpadlibrarian.net/24063077/ro.po

This is probably exacerbated by the fact that we now import Ubuntu translations faster than the build system produces them:

1. Soyuz builds package X for architecture A, uploads its translations.
2. Rosetta auto-approves them, then imports them.
3. Soyuz produces package X for architecture B, uploads the same translations again.
4. Rosetta rejects these because they have the same timestamp as the ones it just imported.

I can't find any way in which this could have happened. I did look at the most recent example I found in the staging import queue (yay for TranslationImportQueueEntry.error_report!) but Launchpad appeared to be right: the latest successful upload for that translation was dated somewhere in 2008, and the newly-uploaded files had a timestamp dating back to 2007.

For now, all I can do is make the email message more helpful and make it show the actual dates involved. Maybe that will lead to new discoveries.

Ok, for all the cases I've investigated (above examples by Martin Pitt for lv.po and ro.po), this is the situation:
 * There was no file upstream imported
 * One gets created (eg. 2007-04-20 19:29+0300 for lv.po; 2008-09-21 23:42+0300 for ro.po from packages)
 * Before that one gets imported, a file in LP is created (2007-04-21 09:38+0300 for lv.po, 2009-02-12 12:22+0200 for ro.po).
 * This causes imported file to be considered as older (i.e. 2007-04-20 vs. 2007-04-21, and 2008-09-21 vs. 2009-02-12).

Solution should be simple: do not check for PO revision date on published imports. Of course, we need to think about what problems will this cause?

Also, uploading a file through Launchpad is what updates the PO-Revision-Date in the DB, so the similar thing happens: upstream file is rejected because it is not newer than what was uploaded through a user upload in LP. That also means that we should ignore PO-Revision-Date on published uploads and it should all be fine.

The matter of the timestamps not being what people might want them to be as bug 356196. Barring news to the contrary, we'll close the issue of equal timestamps being rejected with the pending fix.

Fixed in RF 8153