TypeError: unsupported type for timedelta microseconds component: unicode

[btimby@…]

I have a new installation of Trac 0.12. I am using MySQLdb 1.2.3.

2011-07-25 21:47:28,034 Trac[main] ERROR: Internal Server Error:
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/trac/web/main.py", line 513, in
_dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib/python2.6/site-packages/trac/web/main.py", line 235, in
dispatch
    resp = chosen_handler.process_request(req)
  File "/usr/lib/python2.6/site-packages/trac/wiki/web_ui.py", line 117, in
process_request
    page = WikiPage(self.env, pagename)
  File "/usr/lib/python2.6/site-packages/trac/wiki/model.py", line 44, in
__init__
    self._fetch(name, version, db)
  File "/usr/lib/python2.6/site-packages/trac/wiki/model.py", line 72, in
_fetch
    self.time = from_utimestamp(time)
  File "/usr/lib/python2.6/site-packages/trac/util/datefmt.py", line 84, in
from_utimestamp
    return _epoc + timedelta(microseconds=ts or 0)
TypeError: unsupported type for timedelta microseconds component: unicode

When loading for the first time, I receive the above in the trac log file.

I was able to fix this by simply changing the from_utimestamp function:

def from_utimestamp(ts):
    """Return the `datetime` for the given microsecond POSIX timestamp."""
    return _epoc + timedelta(microseconds=long(ts) or 0)

I am not sure why the time column of the wiki table comes back from MySQLdb as unicode type, but coercing it to a long seems to work properly for me.

[btimby@…]

Patch against 0.12dev for change I made to to from_utimestamp.

[rblank]

Can you please post the schema of the wiki table of your database? The time fields certainly shouldn't be created as strings.

[btimby@…]

The column is a BIGINT. I am not sure why the value is coming through as a unicode value.

CREATE TABLE `wiki` (
  `name` text COLLATE utf8_bin NOT NULL,
  `version` int(11) NOT NULL DEFAULT '0',
  `time` bigint(20) DEFAULT NULL,
  `author` text COLLATE utf8_bin,
  `ipnr` text COLLATE utf8_bin,
  `text` text COLLATE utf8_bin,
  `comment` text COLLATE utf8_bin,
  `readonly` int(11) DEFAULT NULL,
  PRIMARY KEY (`name`(166),`version`),
  KEY `wiki_time_idx` (`time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin

Also, all the values seem proper as well.

mysql> select time from wiki;
+------------------+
| time             |
+------------------+
| 1311636735193901 |
| 1311636735212662 |
| 1311636735222232 |
| 1311636735240462 |
| 1311636735242578 |
| 1311636735245783 |
| 1311636735247188 |
| 1311636735248628 |
| 1311636735250031 |
| 1311636735251380 |
| 1311636735253226 |
| 1311636735254787 |
| 1311636735256447 |
| 1311636735257937 |
| 1311636735259187 |
| 1311636735260529 |
| 1311636735261767 |
| 1311636735262929 |
| 1311636735264274 |
| 1311636735265711 |
| 1311636735266897 |
| 1311636735268112 |
| 1311636735269389 |
| 1311636735271020 |
| 1311636735272590 |
| 1311636735274285 |
| 1311636735275589 |
| 1311636735276922 |
| 1311636735278771 |
| 1311636735280501 |
| 1311636735282442 |
| 1311636735283680 |
| 1311636735285715 |
| 1311636735287916 |
| 1311636735289170 |
| 1311636735290697 |
| 1311636735292057 |
| 1311636735293423 |
| 1311636735294697 |
| 1311636735296203 |
| 1311636735298120 |
| 1311636735300361 |
| 1311636735301601 |
| 1311636735303882 |
| 1311636735305182 |
| 1311636735307020 |
| 1311636735308639 |
| 1311636735309791 |
| 1311636735311073 |
| 1311636735312305 |
| 1311636735313503 |
| 1311636735314842 |
| 1311636735316041 |
| 1311636735317404 |
| 1311636735319086 |
| 1311636735326702 |
| 1311636735327968 |
+------------------+
57 rows in set (0.00 sec)

[rblank]

Weird. Can you please do a:

print repr(ts)

at the beginning of from_utimestamp() and post what it prints right before the exception? MySQLdb should return a long for BIGINT columns.

[rblank]

Oh well. Please reopen if you can provide the requested information.

[anonymous]

Url: "​https://guide.trac.cvsdude.com/denver/login/xmlrpc"
proxy.query("max=0");

Please take a look. and let me know when you got the answer.
eric0622@…

[rblank]

Not sure how this qualifies as the requested information…