Community
Participate
Working Groups
Continuation from bug 127452, which was fixed by adding (very useful) date groups. The original request in that bug is however that the date column should have user-oriented date formats as explained in bug 127452 comment 0, which is repeated below. I think the date column would be much more useable if this enhancement were implemented. With the introduction of the date grouping this becomes even better: a revision in the "Today" category doesn't need the date any more, but should only tell me that it was created "1.5 hours ago". As said in the other bug, I also believe that user-oriented date formatting may be a service that belongs to platform-ui - feel free to move the bug. -- from bug 127452 -- I would like to see a more user-oriented format for displaying revision time stamps. With the local history combined in the history view, this has become even more important, as there are many more revisions, and there are often many local revisions that were created (saved) in short intervals. Ideas: A) Leave out information that is not interesting: - only display the time of day for revisions created on the same day - don't display the year for revisions created this year - leave out the time of day for revisions that were not created this year (perhaps except if there are multiple revisions on the same day - although the sequence of revisions is then more interesting than the exact minute). B) relative time display: the timestamp should answer the question "when was this revision created?". For recent changes, one would usually answer with how old a revision is: "3 minutes ago". - last hour: "3 minutes ago" - same day: "9 AM" - yesterday: "yesterday, 13 PM" - same week: "Tuesday, 8:15" - same year: "July 13" - before: "August 12, 2005" or "08/12/2005" Possible problems: - labels need to be updated as time elapses - probably: needs a user preference...
Created attachment 44983 [details] org.eclipse.team.cvs.ui.diff Provides the requested functionality. The formats for the different time ranges are defined in a resource bundle, since the contain locale-specific formattings.
Created attachment 44984 [details] history_view.png Screenshot of history view running the attached patch.
Thanks for the patch.
Looks good! Here are some comments: - To avoid confusion, I'd like to keep all time formats in a category the same. In order to do that, I'm thinking of the following categories: Today * keep the format from your patch Last Week (rolling 7 days previous to today) * ex. [Monday - Sunday], time Last Month * Jun 16, time (as in your patch) Previous * Apr 21, time * Dec 18 1005, time Note that we should provide the time for all revisions. This will help differentiate multiple entries on the same day and also help guide users who wish to create a date tag.
> - To avoid confusion, I'd like to keep all time formats in a category the same. I agree this is a good idea when "grouping by date" is enabled. I wasn't sure whether we should come up with different labels for grouped and non-grouped mode. I could also imagine a mode where the timestamp label only gives the difference to the group (e.g. if a revision is in the 'Yesterday' group, we wouldn't need to add a weekday or 'Yesterday' label, as this is clear from the group. Could be confusing though.). > In order to do that, I'm thinking of the following categories: > > Today > * keep the format from your patch Would you throw out the "x minutes ago" format and have everything "hh:mm"? This would also avoid having to upate the relative labels as time elapses. Although I still kinda like them... > Last Week (rolling 7 days previous to today) > * ex. [Monday - Sunday], time Is "Last week" currently a category? What I am not sure here is whether a rolling seven day period is the "Last week" in all locales. In German, a weekday usually refers to that day in the current discrete (non-rolling) week. E.g. if today's a Wednesday, then Saturday refers to the future and Monday to the past. Last week's Saturday would be "Last Saturday". But this is not so clear cut and depends on the context, so I guess it would be understandable in the context of the history view, where all dates are in the past. > Last Month > * Jun 16, time (as in your patch) > > Previous > * Apr 21, time > * Dec 18 1005, time > > Note that we should provide the time for all revisions. This will help > differentiate multiple entries on the same day and also help guide users who > wish to create a date tag. Hm, the time just adds noise IMO. A better way would be to state the full timestamp in the details / tags pane. Just my view, though.
I hope this will be an optional feature? Personally I have trouble with time markers like "15 minutes ago" because it leaves since when?" question open.
Although the provided patches look promising, there are two many questions left open and, unfortunately, we don't have the cycles in 3.3 to work out the details.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
