Edgewall Software
Modify

Opened 13 years ago

Closed 12 years ago

#4547 closed defect (fixed)

Timeline page "oops" for new Trac installation

Reported by: sarahg@… Owned by: Christian Boos
Priority: normal Milestone: 0.11
Component: timeline Version: devel
Severity: normal Keywords: datetime
Cc: Branch:
Release Notes:
API Changes:

Description

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.

Attachments (2)

datefmt.patch (2.0 KB ) - added by Dave Abrahams <dave@…> 12 years ago.
updated patch for more resiliency
datefmt-r5696.diff (8.8 KB ) - added by Christian Boos 12 years ago.
Reworked patch, with docstrings and some tests

Download all attachments as: .zip

Change History (19)

comment:1 by anonymous, 13 years ago

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

comment:2 by anonymous, 13 years ago

Resolution: invalid
Status: newclosed

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

comment:3 by Dave Abrahams <dave@…>, 12 years ago

Resolution: invalid
Status: closedreopened

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'

comment:4 by Dave Abrahams <dave@…>, 12 years ago

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

comment:5 by Christian Boos, 12 years ago

Milestone: 0.11
Owner: changed from Jonas Borgström to Christian Boos
Status: reopenednew

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

by Dave Abrahams <dave@…>, 12 years ago

Attachment: datefmt.patch added

updated patch for more resiliency

comment:6 by Dave Abrahams <dave@…>, 12 years ago

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.

comment:7 by Emmanuel Blot, 12 years ago

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 ;-)

in reply to:  7 comment:8 by Dave Abrahams <dave@…>, 12 years ago

Owner: changed from Christian Boos to Emmanuel Blot

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 :)

comment:9 by Christian Boos, 12 years ago

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 ;-)

comment:10 by Dave Abrahams <dave@…>, 12 years ago

Owner: changed from Emmanuel Blot to Christian Boos

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.

comment:11 by Dave Abrahams <dave@…>, 12 years ago

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 ;-)

in reply to:  10 comment:12 by Christian Boos, 12 years ago

Keywords: datetime added
Status: newassigned

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)

by Christian Boos, 12 years ago

Attachment: datefmt-r5696.diff added

Reworked patch, with docstrings and some tests

comment:13 by Christian Boos, 12 years ago

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).

comment:14 by Christian Boos, 12 years ago

in reply to:  13 comment:15 by Dave Abrahams <dave@…>, 12 years ago

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

in reply to:  14 comment:16 by Dave Abrahams <dave@…>, 12 years ago

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.

comment:17 by Christian Boos, 12 years ago

Resolution: fixed
Status: assignedclosed

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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christian Boos.
The resolution will be deleted. Next status will be 'reopened'.
to as closed The owner will be changed from Christian Boos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.