Errored on a CSV file like this from a Trac 1.0.1 instance:
__group__,ticket,summary,component,status,type,priority,owner,modified,_time,_reporter prep,48,Create Stuff,Application,new,build,major,nobody,2014-02-09T05:16:55-05:00,16:14:18-05:00,John Doe
Trace:
Traceback (most recent call last): File "/var/local/allura/ForgeImporters/forgeimporters/base.py", line 131, in import_tool mount_point=mount_point, mount_label=mount_label, **kw) File "/var/local/allura/ForgeImporters/forgeimporters/trac/tickets.py", line 119, in import_tool json.dumps(export(trac_url), cls=DateJSONEncoder), File "/var/local/allura/Allura/allura/scripts/trac_export.py", line 304, in export verbose=verbose, do_attachments=do_attachments) File "/var/local/allura/Allura/allura/scripts/trac_export.py", line 99, in __init__ self.ticket_queue = self.next_ticket_ids() File "/var/local/allura/Allura/allura/scripts/trac_export.py", line 263, in next_ticket_ids r[1]), 'date_updated': self.trac2z_date(r[2])} File "/var/local/allura/Allura/allura/scripts/trac_export.py", line 127, in trac2z_date d = d.astimezone(pytz.UTC) ValueError: astimezone() cannot be applied to a naive datetime
Originally by: yyachim
In my case, Trac 1.0.1 produced timestamps that excluded the timezone designator (i.e. +/-hh:mm) in the CSV file. Skipping the call to astimezone() in seemed to work:
Unrelated to this ticket, but another issue with Trac 1.0.1, is the byte-order mark in the beginning of the CSV file. For me, this caused extra bytes to be included as part of the 'id' key of a dictionary in remap_fields(). I was able to export my data after updating that function to this:
Nice, thanks for the patch!
FYI - this is now live on sourceforge.net
Originally by: yyachim
Thanks for the quick turnaround.