Make timestamps link to timeline

[Christian Boos]

Current focus of this ticket

Provide the ability to link into the timeline.

This could be done using a timeline:<date> TracLinks resolver, where <date> should be specified as using the ​ISO:8601 format.

Another possibility would be to add links to the timeline from various places where dates are displayed in Trac. Most interesting would probably be Changeset dates and Ticket last change (e.g. to find corresponding fix changeset if it wasn't specified otherwise).

Original pipeline-style idea

The timeline should be able to display future events as well as past events, therefore providing a time window around a given present time.

Of course, if the present time is really the present, there would be few future events to show:

• the upcoming Milestones
• a compact representation of the highest and high priority Tickets, maybe simply as a list like that:
  • High Priority Tickets: #9990, #9991, #9992, #9993
  • Highest Priority Tickets: #9994, #9995

But the present could also be set to an arbitrary date. The Timeline view would be very usefull to show what happened that date. In such case, it would be convenient to see what happenened just before and just after that date.

In particular, one could link the changeset timestamps to the Timeline with the present set to the value of that timestamp. In the end any timestamp displayed in Trac could actually be such a link.

[Christopher Lenz]

I really don't think this is a good idea. The timeline is well defined as a list of the project-wide history of events. Reading such a history is trivial and well-understood.

Displaying information useful for scheduling/planning is a totally different beast, and is actually what the roadmap module is intended to provide. I.e. timeline — the past, roadmap — the future.

I can see how unifying the two might appear attractive from a theoretical standpoint… but IMHO mixing them would create a very awkward, hard to understand interface. I'd really need to see a working prototype of such an interface to be convinced.

This might also be related to the "dashboard" feature described in #1.

[Christian Boos]

I'd like to reactivate this one…

Forget the show future milestones and high prio tickets part, and only consider the idea of making the timestamps (e.g. from the changeset) hyperlinks for the timeline at that date.

[Christopher Lenz]

The lets change the summary.

[Christian Boos]

Timestamps in changeset (and wiki history) link back to the Timeline, in order to show the "context" of that event (i.e. what kind of other activity was going on at that time)

[Christian Boos]

Concerning:

In particular, one could link the changeset timestamps to the Timeline with the present set to the value of that timestamp. In the end any timestamp displayed in Trac could actually be such a link.

I have now an implementation for this (attachment:timestamp_href-r2500.patch​) which I think looks quite nice.

Please review.

[Christian Boos]

Updated the above patch for the trunk at r2645

[Christian Boos]

Added updated patch as attachment:timestamp_href-r2645.patch​

Note that you need to apply the patch using patch -p1 (it was generated by Mercurial).

Please review.

[Christian Boos]

If I get no negative feedback when I come back from holidays, I'll assume that everyone liked the patch :)

[Christopher Lenz]

Actually, I'm not convinced I like the change. While the general idea is nice (“see what else happened around this time”), the presentation of the feature to the user is rather unclear IMHO.

I don't have any bright ideas on how to improve this, which is why I haven't commented yet. So I'd prefer not taking no negative feedback as a go in this case. :-P

[Christian Boos]

the presentation of the feature to the user is rather unclear IMHO.

Can you elaborate?

For me, showing the a timeline "window" centered on the event seems to address the problem quite well (i.e. show what happened around that event). Furthermore, the event itself is highlighted.

That's already quite useful. It could be improved upon, perhaps (I also don't see how), but what's bad about providing a first draft, maybe not perfect the first time?

Then, some users may see the feature, think about an improvement, and push the thing forward…

Keeping this aside will most probably make the feature die, for no good reason (IMHO too).

[Christian Boos]

I propose to resurrect this one, forgetting about the time window thing around the event (until a "clearer" way to present it to the user is found), and simply add the timeline:YYYY-MM-DD TracLinks resolver, for jumping to the timeline at a specific day (adopting the ​ISO:8601 format which is the less unambiguous and the easier to justify).

[Christian Boos]

Updated patch for 0.11

[Christian Boos]

Patch attachment:timeline_link_resolver-r4452.diff​ updated for current trunk. The time window thing that cmlenz objected to above is gone. Now you just provide a regular from argument to the timeline.

Still, the events which are within an hour of the specified time are highlighted (when the time is specified in addition to the date).

There are also a bunch of bug fixes to the timezone selection (most notably the ± signs for the timezones were reversed).

[Jonas Borgström]

Are you sure the bundled timezone implementation is incorrect? Please compare it against the pytz module.

For example: "CET" is currently the same as "Etc/GMT-1" not "Etc/GMT+1":

​http://www.gsp.com/support/virtual/admin/unix/tz/gmt/

[Christian Boos]

Well, I did some research, and I found the origin of the confusion. This comes from the choice of the convention (POSIX), which is at odds with the usually accepted convention (ISO). That confusion is quite common, see the following mail exchange for example:

• ​http://sources.redhat.com/ml/glibc-bugs/2005-10/msg00070.html
• ​http://sources.redhat.com/ml/glibc-bugs/2005-10/msg00071.html

The choice of the POSIX convention goes the reverse way of the usual convention, which is to prefix with "+" the time zones eastern of Greenwich:

• ​Wikipedia:Central_European_Time
• ​http://timeanddate.com/worldclock/city.html?n=332
• ​Wikipedia:Time_zone#Standard_time_zones
• ​ISO:8601#Time_zones

So outside of the UNIX context, that convention makes little sense. For example, on Windows, the Date and Time Properties panel lists the CET time zone as:

• (GMT +01:00) Brussels, Copenhagen, Madrid, Paris

In order to be unambiguous, I propose that we use the ISO standard names for our FixedZone implementation, not the the UNIX-oriented one: ​UTC+1.

Further testing with ​pytz shows that they also use internally the "+" sign for eastern timezones:

>>> import pytz
>>> from datetime import datetime
>>> cet = pytz.timezone('CET')
>>> cet
<DstTzInfo 'CET' CET+1:00:00 STD>

(note the "+1" here)

>>> utc = pytz.timezone('UTC')
>>> now = datetime.now(utc)
>>> now
datetime.datetime(2006, 12, 15, 8, 4, 22, 609000, tzinfo=<UTC>)
>>> now.astimezone(cet)
datetime.datetime(2006, 12, 15, 9, 4, 22, 609000, tzinfo=<DstTzInfo 'CET' CET+1:00:00 STD>)

… but right, they stick to the POSIX conventions for the "Etc/GMT" time zones:

>>> gmt_plus_1 = pytz.timezone('Etc/GMT+1')
>>> gmt_plus_1
<StaticTzInfo 'Etc/GMT_plus_1'>
>>> now.astimezone(gmt_plus_1)
datetime.datetime(2006, 12, 15, 7, 4, 22, 609000, tzinfo=<StaticTzInfo 'Etc/GMT_plus_1'>)

So in the case of pytz, I'd suggest that either we override the ambiguous and unixish (*) 'Etc/GMT-1' kind of names and replace them by the unambiguous 'UTC+1' names or that we add a note about how those 'etcetera' time zones should be interpreted, as I suppose I won't be the only one to get confused.

[Christian Boos]

In internet protocols also, the usage of "+" correspond to eastern timezones:

The "+" or "-" indicates whether the time-of-day is ahead of (i.e., east of) or behind (i.e., west of) Universal Time. (​RFC:2822 #s3.3)

See also ​RFC:3339, #s4.2

So I updated patch to use strings like "GMT +01:00".

Also, I modified the format_datetime helper function and the dateinfo macros so that we get links to the timeline from various places (e.g. changeset time, ticket created and last modified time, browser age, wiki history, …).

Actually, instead of the patch, what about yet another work branch? (as this makes it easier to review the changes and eventually fine tune them before the integration).

See source:sandbox/timeline-link-resolver-tmp.

[Christian Boos]

Show how the created date and last modified date are displayed using r4538

[Christian Boos]

Show how the timeline looks like when following the link for the last modified date shown in the previous snapshot

[Christian Boos]

Here's an example for the additional automatic timeline links:

By following the "Last modified 1 month ago" link, one goes back to the timeline:

[Christian Boos]

Implemented in [4645:4651].