Edgewall Software

Opened 11 years ago

Closed 11 years ago

Last modified 7 years ago

#9777 closed enhancement (fixed)

New option for displaying absolute date/time in ticket — at Version 15

Reported by: anonymous Owned by: Jun Omae
Priority: normal Milestone: 1.0
Component: general Version: 0.12.1
Severity: normal Keywords: preferences
Cc: trac@…, leho@… Branch:
Release Notes:

Added a user preference and a option to display relative/absolute datetime.

API Changes:

Provide pretty_dateinfo function which displays relative/absolute datetime in the user preferences and default_dateinfo_format option.

Internal Changes:


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

Change History (19)

by anonymous, 11 years ago

sample plugin with absolute date/time (amongst others)

by anonymous, 11 years ago

Attachment: ticket_box.html added

inside templates folder is a sample ticket-box.html

comment:1 by anonymous, 11 years ago

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

comment:2 by Remy Blank, 11 years ago

Milestone: 0.13next-major-0.1X

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

comment:3 by Reinder <trac@…>, 11 years ago

Cc: trac@… added

comment:4 by hushker@…, 11 years ago

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?

comment:5 by Ryan J Ollos <ryano@…>, 11 years ago

Cc: ryano@… added

comment:6 by Christian Boos, 11 years ago

Keywords: userpreferences added

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.

in reply to:  6 comment:7 by Jun Omae, 11 years ago

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'].

comment:8 by Christian Boos, 11 years ago

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

    commit 56ea961f74d3fa2ad25215e15bbebf99a202f473
    Author: Christian Boos <cboos@neuf.fr>
    Date:   Wed Mar 2 23:03:09 2011 +0100
        #9777: improve absolutetime when `dateonly=False`
    diff --git a/trac/timeline/web_ui.py b/trac/timeline/web_ui.py
    index ba65282..54cbff7 100644
    a b from trac.core import *  
    2828from trac.perm import IPermissionRequestor
    2929from trac.timeline.api import ITimelineEventProvider
    3030from trac.util import as_int
    31 from trac.util.datefmt import format_date, format_datetime, parse_date, \
    32                               to_utimestamp, utc, pretty_timedelta, user_time
     31from trac.util.datefmt import format_date, format_datetime, format_time, \
     32                              parse_date, to_utimestamp, utc, \
     33                              pretty_timedelta,  user_time
    3334from trac.util.text import exception_to_unicode, to_unicode
    3435from trac.util.translation import _, tag_
    3536from trac.web import IRequestHandler, IRequestFilter
    class TimelineModule(Component):  
    273274                    format = req.session.get('dateinfo') or \
    274275                             Chrome(self.env).dateinfo_format
    275276                if format == 'absolute':
    276                     label = absolute
    277                     title = _("%(relativetime)s ago in Timeline",
     277                    if dateonly:
     278                        label = absolute
     279                    else:
     280                        label = _("on %(date)s at %(time)s",
     281                                  date=user_time(req, format_date, date),
     282                                  time=user_time(req, format_time, date))
     283                    title = _("See timeline %(relativetime)s ago",
    278284                              relativetime=relative)
    279285                else:
    280286                    label = _("%(relativetime)s ago", relativetime=relative) \
    281287                            if not dateonly else relative
    282                     title = _("%(absolutetime)s in Timeline",
     288                    title = _("See timeline at %(absolutetime)s",
    283289                              absolutetime=absolute)
    284290                return self.get_timeline_link(req, date, label,
    285291                                              precision='second', title=title)

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

comment:9 by Christian Boos, 11 years ago

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

comment:10 by Remy Blank, 11 years ago

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

in reply to:  8 comment:11 by Jun Omae, 11 years ago

Milestone: next-major-0.1X0.13
Owner: set to Jun Omae
Status: newassigned

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

  • trac/timeline/web_ui.py

    diff --git a/trac/timeline/web_ui.py b/trac/timeline/web_ui.py
    index 8d57b8b..2a493e4 100644
    a b class TimelineModule(Component):  
    276276                if format == 'absolute':
    277277                    if dateonly:
    278278                        label = absolute
     279                    elif req.lc_time == 'iso8601':
     280                        label = _("at %(iso8601)s", iso8601=absolute)
    279281                    else:
    280282                        label = _("on %(date)s at %(time)s",
    281283                                  date=user_time(req, format_date, date),
    class TimelineModule(Component):  
    329331        iso_date = format_datetime(date, 'iso8601', req.tz)
    330332        href = req.href.timeline(from_=iso_date, precision=precision)
    331333        return tag.a(label or iso_date, class_='timeline',
    332                      title=title or _("%(date)s in Timeline", date=iso_date),
     334                     title=title or _("See timeline at %(absolutetime)s",
     335                                      absolutetime=iso_date),
    333336                     href=concat_path_query_fragment(href, query, fragment))
    335338    # 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

comment:12 by Jun Omae, 11 years ago

API Changes: modified (diff)
Release Notes: modified (diff)
Resolution: fixed
Status: assignedclosed

Committed in [10629].

by anonymous, 10 years ago

Attachment: ticket_9777_msgstr.diff added

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

comment:13 by lkraav <leho@…>, 9 years ago

Cc: leho@… added

by lkraav <leho@…>, 9 years ago

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

comment:14 by lkraav <leho@…>, 9 years ago

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.

comment:15 by Ryan J Ollos <ryan.j.ollos@…>, 9 years ago

API Changes: modified (diff)
Note: See TracTickets for help on using tickets.