Timeline page "oops" for new Trac installation

[sarahg@…]

I've been testing the current trunk for Trac and a freshly created trac db produces the following error when I visit its "timeline" page:

Oops…
Trac detected an internal error:

AttributeError: 'float' object has no attribute 'astimezone'

There was an internal error in Trac. It is recommended that you inform your local Trac administrator and give him all the information he needs to reproduce the issue.

To that end, you could ==== How to Reproduce ==== While doing a GET operation on `/timeline`, Trac issued an internal error. ==== System Information ==== || '''Trac''' || `0.11dev` || || '''Python''' || `2.4.3 (#1, Jun 22 2006, 11:18:23) `[[br]]`[GCC 3.4.5 20051201 (Red Hat 3.4.5-2)]`[[br]] || || '''SQLite''' || `3.3.5` || || '''pysqlite''' || `2.2.0` || || '''Genshi''' || `0.4dev-r469` || ==== Python Traceback ==== {{{ Traceback (most recent call last): File "/usr/local/python/lib/python2.4/site-packages/trac/web/main.py", line 395, in dispatch_request dispatcher.dispatch(req) File "/usr/local/python/lib/python2.4/site-packages/trac/web/main.py", line 213, in dispatch resp = chosen_handler.process_request(req) File "/usr/local/python/lib/python2.4/site-packages/trac/Timeline.py", line 112, in process_request req.hdf['timeline.from'] = format_date(fromdate) File "/usr/local/python/lib/python2.4/site-packages/trac/util/datefmt.py", line 69, in format_date return format_datetime(t, format, tzinfo=tzinfo) File "/usr/local/python/lib/python2.4/site-packages/trac/util/datefmt.py", line 60, in format_datetime t = t.astimezone(tzinfo) AttributeError: 'float' object has no attribute 'astimezone' }}} a ticket at this site.

The action that triggered the error was:

GET: /timeline

TracGuide — The Trac User and Administration Guide

I was using revision [4576] of trac, and in case it was just a problem with a specific revision I also tried [4566], [4556] and [4500]. They all seem to have this timeline problem.

[anonymous]

This looks like its related to #4497 but isn't the same message.

[anonymous]

Never mind… I removed the old installed files and re-installed the current trac and now the timeline is working.

[Dave Abrahams <dave@…>]

I'm seeing this too, in the trac development version, with the TracDiscussionPlugin installed. The following patch makes it go away for me:

Index: trac/util/datefmt.py
===================================================================
--- trac/util/datefmt.py        (revision 5487)
+++ trac/util/datefmt.py        (working copy)
@@ -59,7 +59,7 @@
         tzinfo = localtz
     if t is None:
         t = datetime.now(utc)
-    if isinstance(t, (int,long)):
+    if isinstance(t, (int,long,float)):
         t = datetime.fromtimestamp(t, tzinfo)
     if format.lower() == 'iso8601':
         format = '%Y-%m-%dT%H:%M:%SZ%z'

[Dave Abrahams <dave@…>]

Seems like checking for !isinstance(t, datetime.datetime) might be a lot less brittle, though.

[Christian Boos]

So this would let datetime.fromtimestamp take the responsibility to throw an error in case it's given something it can't handle. I guess this would be OK, as the exception will be clearer:

>>> datetime.fromtimestamp("x")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: a float is required

[Dave Abrahams <dave@…>]

updated patch for more resiliency

[Dave Abrahams <dave@…>]

In trying to make TracDiscussion work with 0.11dev, I found other places where the plugin was expecting datefmt to be more resilient and liberal with incoming types. As such I submit the attached updated patch. I realize this could be considered a bug in the plugin; somebody really needs to document the requirements of the datefmt API.

[Emmanuel Blot]

I think that in order to be coherent with other discussions and decisions about formats in plugin vs. Trac core (UTF-8: #4875, …), it's up to the plugin to provide the appropriate data format, which is yet to be documented.

As usual, help and patch are welcomed, including Python doc strings ;-)

[Dave Abrahams <dave@…>]

Replying to eblot:

I think that in order to be coherent with other discussions and decisions about formats in plugin vs. Trac core (UTF-8: #4875, …), it's up to the plugin to provide the appropriate data format, which is yet to be documented.

As usual, help and patch are welcomed, including Python doc strings ;-)

I'll be happy to add the doc strings that document the requirements currently imposed by my patched version of datefmt.py, but I don't want to waste my time: someone needs to bless those new, more-lenient, requirements for me. Just tell me how you want it to work so we can close this ticket :)

[Christian Boos]

The appropriate input for those functions should be a datetime object, but for robustness w.r.t to other input types provided by plugins, we should apply the patch. It's similar to what we do with e.g. wiki macros plugins, where we require unicode output but nevertheless use to_unicode just to be sure ;-)

[Dave Abrahams <dave@…>]

I'm not a fan of implementations that intentionally allow incorrect input to "work" (can you say perl?) I'd much rather document the actual requirements; otherwise there will be confusion about which client code is actually broken, or even whether the docs are proken. That said, I'm willing to do whatever is needed to close this ticket. If you confirm you want me to add documentation to the patch that requires datetime objects, I'll do that.

[Dave Abrahams <dave@…>]

Not to make this more difficult than it needs to be, but I was just pondering what it would take to clean up the TracDiscussion plugin if the requirement becomes that datetime objects are passed. To make TracDiscussion correct I'd have to repeat the same _normalize function I'm using in datefmt.py. The prospect of having little, subtly-different clones of that function scattered around the Trac universe seems really unattractive to me. IMO either it should be factored out and made part of Trac's public interface or the datefmt argument requirements should be liberalized…

…and that, I promise, is my last statement of opinion. It's not my project, so I'll do whatever the trac gods ask ;-)

[Christian Boos]

Replying to Dave Abrahams <dave@boost-consulting.com>:

I'm not a fan of implementations that intentionally allow incorrect input to "work" (can you say perl?) I'd much rather document the actual requirements;

Well, we can do both: document the requirements for 0.11 and be robust against other inputs, then later (0.12), enforce the requirements. The datetime stuff is new in 0.11, so that will make an easy upgrade path.

That said, I'm willing to do whatever is needed to close this ticket. If you confirm you want me to add documentation to the patch that requires datetime objects, I'll do that.

Well, I'm currently working on it (started from your patch), so you want to review my fix in a couple of minutes ;-)

(point taken for making normalize part of the public API)

[Christian Boos]

Reworked patch, with docstrings and some tests

[Christian Boos]

See attachment:datefmt-r5696.diff​

I've renamed _normalize to to_datetime, which is reminiscent of to_unicode as it serves the same kind of normalization purpose (here: datetime/timestamps → datetime).

[Christian Boos]

See also: ​googlegroups:trac-dev:9edad322bc911e6f

[Dave Abrahams <dave@…>]

Tried to add this comment <​http://paste.lisp.org/display/43332>, but instead "Trac detected an internal error"

[Dave Abrahams <dave@…>]

Replying to cboos:

See also: ​googlegroups:trac-dev:9edad322bc911e6f

The answer to your question, "what's the alternative?" is simple: it could be an error.

[Christian Boos]

The datefmt stuff will likely be reworked in 0.12 to work with Babel (see babel:wiki:Documentation/dates.html), so I think the current patch is good enough in the meantime (r5754).

Note that the convention to use the current time when None is also in use there (babel:source:trunk/babel/dates.py). I think this is OK, the alternative would be to use datetime.now(utc) (as the timezone is mandatory for datetime differences), which is more verbose and therefore not that clearer.