New option for displaying absolute date/time in ticket

[anonymous]

In my company it is prefered that changes are displayed as "Created at 05.11.2010 16:40" (absolute/exact) instead of "x days ago" (relative).

So it would be nice when in trac.ini would be a config-param, which indicates if the date should be displayed in absolute or relative mode.

Or maybe realizing it like in #2226

[anonymous]

sample plugin with absolute date/time (amongst others)

[anonymous]

inside templates folder is a sample ticket-box.html

[anonymous]

this feature is also meant for comments, maybe it could/should be applied trac-wide oris user-specific an option

[Remy Blank]

If this is implemented, it should be a user preference.

[hushker@…]

Is this plugin usable? I tried to install it with admin page, but cannot see it in plugin list. I wrote this in trac.ini [ticket] date_format = absolute

and changed ticket_box.html to the attachment, but it had no effect. Can you write how to make it work please?

[Christian Boos]

There was also a ticket for displaying absolute dates for comments, #5813. We eventually need to make this a user preference and use it broadly, especially now that we have #2182 and that people will perhaps prefer to see the dates in the format they're most familiar with.

Instead of having ... ${dateinfo()} ago ... all over the place in the templates, we should have simply ... ${dateinfo()} ..., and have that replaced with either a _("%(relativetime)s ago") or _("%(absolutetime)s"), depending on the new preference.

Also, in trac.timeline.web_ui.get_timeline_link()​ we should probably use user_time(), as 'datefmt' is not what is used today.

[Jun Omae]

I worked the issue in my branch, ​https://github.com/jun66j5/trac/compare/t9777-absolute-datetime.

Instead of having ... ${dateinfo()} ago ... all over the place in the templates, we should have simply ... ${dateinfo()} ..., and have that replaced with either a _("%(relativetime)s ago") or _("%(absolutetime)s"), depending on the new preference.

dateinfo function is expected that X is not contained in the output. Also, maybe some plugins use the function. So, I think that dateinfo should not be changed for the compatibility and add new function instead of that.

In the branch, added new pretty_dateinfo function which returns _("%(relativetime)s ago") or _("%(absolutetime)s") depending on req.session['dateinfo'].

[Christian Boos]

Sure, you're right about backward compat.

Now about the changes: they're nearly exactly what I had in mind … only better ;-)

A few comments:

• in Chrome.pretty_dateinfo: req.session.get('dateinfo') or self.dateinfo_format could be simply req.session.get('dateinfo', self.dateinfo_format) (same for the pretty_format in timeline)
• ​7304a8cc40c4695792db is just great ;-)
• ​1c5de2ea3541c0affdd7, I have some reservation: instead of e.g. (${pretty_dateinfo(change.date, format='relative')}) can't we simply put back (${dateinfo(change.date)} ago)? Shorter, no changes for the translations.

Now testing the stuff…

• we need the 1c5de2ea3541c0affdd7 fixup in the changeset Timestamp: as well (always relative in ())
• maybe the timeline link titles could be enhanced like this:
  • "See timeline %(relativetime)s ago"
  • "See timeline at %(absolutetime)s"

The translations will not always be optimal. For example in French the sentence Last modified ${pretty_dateinfo(page.time)} can be translated to:

• either Dernière modification il y a 3 jours (relative time, entirely correct)
• or Dernière modification 15 févr. 2011 15:39:50 (absolute time, incorrect); the correct translation would have been: Dernière modification le 15 févr. 2011 15:39:50 or even better: Dernière modification le 15 févr. 2011 à 15:39:50

Hold on a minute! It's in fact exactly the same for the English sentence. For absolute time we would need something like Last modified on Feb 15, 2011 at 3:39:50 PM.

However showing the long form on Feb 15, 2011 at 3:39:50 PM systematically won't work when we're not in a sentence (e.g. in the Date column in Wiki history). Maybe we need to use the dateonly param for absolute time as well, when needed.

trac/timeline/web_ui.py

@@ -28 +28 @@
 from trac.perm import IPermissionRequestor
 from trac.timeline.api import ITimelineEventProvider
 from trac.util import as_int
-from trac.util.datefmt import format_date, format_datetime, parse_date, \
-                              to_utimestamp, utc, pretty_timedelta, user_time
+from trac.util.datefmt import format_date, format_datetime, format_time, \
+                              parse_date, to_utimestamp, utc, \
+                              pretty_timedelta,  user_time
 from trac.util.text import exception_to_unicode, to_unicode
 from trac.util.translation import _, tag_
 from trac.web import IRequestHandler, IRequestFilter
@@ -273 +274 @@
                     format = req.session.get('dateinfo') or \
                              Chrome(self.env).dateinfo_format
                 if format == 'absolute':
-                    label = absolute
-                    title = _("%(relativetime)s ago in Timeline",
+                    if dateonly:
+                        label = absolute
+                    else:
+                        label = _("on %(date)s at %(time)s",
+                                  date=user_time(req, format_date, date),
+                                  time=user_time(req, format_time, date))
+                    title = _("See timeline %(relativetime)s ago",
                               relativetime=relative)
                 else:
                     label = _("%(relativetime)s ago", relativetime=relative) \
                             if not dateonly else relative
-                    title = _("%(absolutetime)s in Timeline",
+                    title = _("See timeline at %(absolutetime)s",
                               absolutetime=absolute)
                 return self.get_timeline_link(req, date, label,
                                               precision='second', title=title)

user_time has better to be well optimized, we're calling it 3 times here ;-)

[Christian Boos]

Btw, if some native English speaker pass by (or Remy ;-) ), proofing of the sentences "on %(date)s at %(time)s" and "See timeline at %(absolutetime)s" would be welcome. I especially have a doubt about the latter (s/at/on/?).

[Remy Blank]

Looks good to me. I would keep "See timeline at …", but I'm not a native English speaker.

[Jun Omae]

Ok, update ​the branch with your review and suggestions, thanks! And tweaked when selecting iso8601 format.

trac/timeline/web_ui.py

@@ -276 +276 @@
                 if format == 'absolute':
                     if dateonly:
                         label = absolute
+                    elif req.lc_time == 'iso8601':
+                        label = _("at %(iso8601)s", iso8601=absolute)
                     else:
                         label = _("on %(date)s at %(time)s",
                                   date=user_time(req, format_date, date),
@@ -329 +331 @@
         iso_date = format_datetime(date, 'iso8601', req.tz)
         href = req.href.timeline(from_=iso_date, precision=precision)
         return tag.a(label or iso_date, class_='timeline',
-                     title=title or _("%(date)s in Timeline", date=iso_date),
+                     title=title or _("See timeline at %(absolutetime)s",
+                                      absolutetime=iso_date),
                      href=concat_path_query_fragment(href, query, fragment))
 
     # Internal methods

However showing the long form on Feb 15, 2011 at 3:39:50 PM systematically won't work when we're not in a sentence (e.g. in the Date column in Wiki history). Maybe we need to use the dateonly param for absolute time as well, when needed.

In the history view, shows Oct 1, 2010 9:40:01 PM or 5 months with dateonly=True. ​https://github.com/jun66j5/trac/compare/t9777-absolute-datetime#diff-3

[Jun Omae]

Committed in [10629].

[anonymous]

diff of message.pot, indicating missing message strings of this ticket

[lkraav <leho@…>]

feature backport to 0.12, rebases cleanly on top of 0.12.4dev d3fcd42

[lkraav <leho@…>]

Perhaps any of the core guys is interested in taking a look for 0.12.4, backporting the feature was fairly uninvasive. Granted I've only been running with it for a day, so lack of side-effects is not entirely guaranteed just yet.

[lkraav <leho@…>]

If I could edit the previous comment, I'd edit it and say:

EDIT the patchset above is not complete after all and won't work ootb

[Ryan J Ollos <ryan.j.ollos@…>]

You reverted my typo fix! ;)