Patch #14567
Updated by Toshi MARUYAMA over 11 years ago
In Trac API 0.12, the representation of timestamps was changed from seconds since the epoch to microseconds since the epoch: http://trac.edgewall.org/wiki/TracDev/ApiChanges/0.12#Timestampstorageindatabase See this patch that changed it in Trac: http://trac.edgewall.org/attachment/ticket/6466/6466-microsecond-times-r8770.patch If you try to run the existing migrate_from_trac.rake script, the year will be thousands of years in the future, and the importer will populate the date in redmine is 0000000000. This causes many things to break. The problem still exists with the trunk version of the migrate_from_trac.rake script. In http://www.redmine.org/issues/882 , the user encountered the problem, but went down the wrong path with the fix, because he didn't understand why timestamps were being imported incorrectly. I am submitting a better fix, which detects the database version of Trac. If the database version is > 22, then every time a timestamp from Trac is encountered, we divide by 1 million. This patch is against trunk. I have used this patch successfully and it fixes all my problems importing from Trac. I think many people are hitting these issues when doing Trac -> Redmine migrations. Here are some example tickets: #5764 http://www.redmine.org/issues/5764 #8690 http://www.redmine.org/issues/8690 #12477 http://www.redmine.org/issues/12477