File attachment 'added' time is incorrect

[robert.nadler@…]

Found in r6814.

The added time shown in the ticket is correct:

MTM1.log (1.6 kB) - added by admin 2 days ago.

but when you show the file, the added time is incorrect:

File MTM1.log, 1.6 kB (added by admin, 84 seconds ago)

The tool-tip timestamp is the same (and correct) on both.

[sid]

sample file to see if problem with timestamps can be replicated

[Christian Boos]

Yeah, it's because we're sending a 304 response in this case (trunk/trac/attachment.py@6980#L622​).

Maybe we can use the same approach as for changesets here (i.e. the less than one hour ago trick, trunk/trac/versioncontrol/web_ui/changeset.py@6980#L295​), so that we can at the same time show a valid information to the user and minimize the number of page reloads.

[Peter Suter]

Yeah, it's because we're sending a 304 response in this case (trunk/trac/attachment.py@6980#L622​).

Maybe we can use the same approach as for changesets here (i.e. the less than one hour ago trick, trunk/trac/versioncontrol/web_ui/changeset.py@6980#L295​), so that we can at the same time show a valid information to the user and minimize the number of page reloads.

I think this refers to the req.check_modified(attachment.date, ...​ cal:

This call (sending a 304 response) may allow the browser to show a previously cached page, which might contains the outdated timestamp.

But if something like this​ would also be added to the attachment template​, then "84 seconds ago" would be shown as "less than one hour ago" instead. So the cached page wouldn't instantly become obsolete.

To ensure the browser stops using the cached page once it does become obsolete, pretty_timedelta(..., 3600)​ (resolution of 3600 seconds i.e. one hour) would be added to that check_modified call.