Here is a solution if you ever come across this annoying bug listed on metalink [Bug 8900173]::

When importing through Archiver, there are situations where there is no setting that will allow for all content items to be imported in an archive due to anomolies in the ReleaseDate (dInDate) and CreateDate (dCreateDate) of different content items.

This can cause a catch-22 type situation where using the UseRvisionCreateDate=true setting will allow content to import that have dInDate out of order for its revisions, but the content items with revisions of dCreateDate out of order will fail. Similarly disabling the UseRevisionCreateDate=true setting will allow the items that failed in the previous scenario to import, but items whose dInDate is out of order will fail to import..

There are workarounds for this issue (e.g. multiple archives and turning on / off the UseRevisonCreateDate setting on the target server, or modifying the source Revisions table’s dCreateDate values), but depending on the number of content items that have the problem, this can be an extremely tedious process.

#####

Import error for archive ‘<archive>’ in collection ‘<collection>’: Content item ‘<item>’ with revision label ‘<revision number>’ was not successfully checked in. The release date (28/07/2006 9:11) of the new revision is not later than the release date (28/07/2006 9:11) of the latest revision in the system.

Import error for archive ‘<archive>’ in collection ‘<collection>’: Content item ‘<item>’ with revision label ‘<revision number>’ was not successfully checked in. The creation date (26/02/2009 13:26) of the new revision is not later than the creation date (31/03/2009 14:09) of the latest revision in the system.

#####

Read on for the Fix

Now if you have over 100,000 content items to import like I did; there was no way I was going to manually change all of the dates and btw turning UseRevisonCreateDateon and off does not really help at all; you get either 1 of the errors above and still not all content appears to check in..
So how do you import all 100,000 revision when you get this date bug on import which prevent a whole lot of revisions from being  imported?

First the easy method – which I didn`t try but looking at my archive should work..
Set SystemDateFormat in the config.cfg to use seconds and milliseconds; you will need to restart any Content Server then do the import.

If you dont want to change your system to use seconds/milliseconds you should be able to disable SystemDateFormat after the import and restart the content server.

Alternatively try this hack

In Archiver select the import tab.
Select Edit under the value maps.
Make sure you have the ALL check box enabled.
Add Release Date under field option list and set it to a future date ie 02/02/2020 11:00
Add Expiration Date under field option list and set it to a future date ie 03/03/2020 11:00
When setting the date make sure it conforms to your date/time settings

Hit ok and browser to your archive folder <UCM>/archives/<myarchive>
Open up the arcive.hda from within <myarchive> in wordpad
Scroll down to aValueMaps=
On this line you should see a clauses section in here you will have to manually add dCreateDate

1::dCreateDate:01/01/2020%11*00

[The clauses are comma separated]

Save the update.
Now do an import this will import all of your content.
Yes it will also change the dates.
When the update has complete remove the import maps
You should also see dCreateDate is in there so you can remove it without hacking the hda file.
Do another archive import update. – This should update all your date meta fields

That’s it all content is now successfully archived into the UCM with the correct meta info assigned.