time data ... does not match format '%Y-%m-%dT%H:%M:%S'

[carrott]

ValueError: time data dbus.ByteArray('1268087339', variant_level=1) does not match format '%Y-%m-%dT%H:%M:%S'
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/jarabe/journal/listmodel.py", line 124, in on_get_value
    return self._cached_row[column]
IndexError: list index out of range

Saw the above in Samoa on os300py on XO-1. I'm not sure what the context was, if a journal backup helps, I can possibly dig one up.

See the attached log file for more context.

[sascha_silbe]

There was a potentially related  thread on sugar-devel recently.

[carrott]

This appears to be related to #2149. I migrated a bunch of laptops from 767 to os300py, and it appears that even with the patch in #2149, migration does not proceed completely successfully.

I think this ticket could be closed as a dupe of #2149.

[sascha_silbe]

A tarball of the data store (if I don't already have it) and the name or uid of the entry that triggered this bug would be useful as I couldn't reproduce it using the (combined) content of the data stores you sent me. I do get some other errors that we should catch, but not the one about the date format. Maybe I just didn't examine the right entry (by openening the details view).

[tomeu]

Guess this got moved to the sugar component by mistake

[sascha_silbe]

The error message is from sugar and as long as I can't reproduce and diagnose it, that's our best guess as to which component needs to be fixed. Or rather, sugar should be fixed in any case, even if it turns out we're doing something wrong during migration. Invalid metadata should be handled gracefully, not break the Journal.

[tomeu]

Replying to sascha_silbe:

The error message is from sugar and as long as I can't reproduce and diagnose it, that's our best guess as to which component needs to be fixed. Or rather, sugar should be fixed in any case, even if it turns out we're doing something wrong during migration. Invalid metadata should be handled gracefully, not break the Journal.

In any case, it would be journal, though I don't fully understand why we have only one ticket and not two if the idea is that something is wrong in the DS *and* we want the journal to be more tolerant to bad data coming from the DS.

[alsroot]

I've checked ds and sugar sources, except attached patch there are no other not-try-excepted time.strptime calls.

[sascha_silbe]

Replying to tomeu:

In any case, it would be journal,

Good point. I only thought about the git repo it lives in, but you're right there's a separate component in Trac for this part of the code.

though I don't fully understand why we have only one ticket and not two if the idea is that something is wrong in the DS *and* we want the journal to be more tolerant to bad data coming from the DS.

Because we don't know yet if the data store is to blame. It could very well have been an activity that wrote the invalid mtime property, in which case there probably is nothing else to fix (because it most likely was an ancient version and has long been fixed)..

Replying to alsroot:

I've checked ds and sugar sources, except attached patch there are no other not-try-excepted time.strptime calls.

I would replace the %s with %r so any special characters get escaped and the string gets quoted, but other than that the patch looks obviously fine (haven't tested it).

[sascha_silbe]

Fixed in 0.92 by  923a7fc ( 760deeb for 0.90).