Patch #14567
openmigrate_from_trac.rake does not convert timestamps in Trac database version 23
0%
Description
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 #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:
Files
Related issues