Roundup Tracker - Issues

Issue 679232

classification
Interval pretty() before/after now
Type: Severity: normal
Components: None Versions:
process
Status: closed fixed
:
: : lukeopperman, richard
Priority: normal :

Created on 2003-02-02 22:34 by lukeopperman, last changed 2003-02-07 01:08 by richard.

Messages
msg626 Author: [hidden] (lukeopperman) Date: 2003-02-02 22:34
For displaying (as an example) due dates (as opposed to
Activity, which is always in the past),
date.Interval.pretty() does not handle the Interval
sign in a consistent manner. A few possibilities do
("tomorrow/yesterday"), but just noticed in our tracker
we have two items due in "2 days", except one is two
days overdue and the other is two days in the future.



Really simple fix diff attached below (this is diffed
as part of my other modifications in "date.py
modifications bug against 0.5.5 source, so if the line
numbers are off, this goes in Interval.pretty()
immediately before "return s", line 463 in the 0.5.5
original):


...site-packages/roundup# diff date.py date_orig.py
490,491d463
<         if self.sign < 0:
<             s = s + _(' ago')
msg627 Author: [hidden] (richard) Date: 2003-02-06 01:10
Logged In: YES 
user_id=6405

I'd rather not add "ago" to the pretty interval, since it's the most common 
case and will pad out the field. Any suggestion for another way to 
distinguish the two cases? 
 
msg628 Author: [hidden] (lukeopperman) Date: 2003-02-06 16:07
Logged In: YES 
user_id=700949

Understandable. Looking at my activity columns, it pushes 
out one or two chars versus "yesterday" (the previous 
common long entry), except on "minutes ago", which "ago" is 
entirely extra. This will obviously depend on font etc, but I see 
the issue.

Alternatives off the top of my head:

* prefix future intervals with "in ". This doesn't really help me, 
because then past ones are still easy to confuse (for our use, 
the fact that "ago" pushes out is actually very helpful for 
visually identifying overdue items).

* prefix with sign (+/-). Downside: it's not so pretty anymore, 
and negative dates ("- 7 days") aren't particularily intuitive.

* abbreviate the common pretty words "hours, minutes" 
to "hrs, mins". at least in our setup this makes it so worst 
case is an additional single character pushout by "ago". 
(Again, compared to "yesterday".) Downsides: "months" still 
pushes 2+ chars, and has no good abbreviation I can think of, 
and abbreviations are just less pretty.

* make the "ago/in" suffix/prefix optional by argument to 
pretty. I dislike adding arguments, and this doesn't address 
the fact that the default behavior is ambiguous, but if my use 
is the exception to most use of pretty-printing intervals, I'm ok 
with it.

Basically, for our needs "ago" is a very good solution. (it even 
helped on the activity column, because some users were 
misunderstanding th column to mean "work activity time 
spent on this item". We changed the title to "Last Update" as 
well, so that's not a strong endorsement for "ago".) But I 
would accept this as optional behavior via an argument or 
using abbreviations as my next choices.
msg629 Author: [hidden] (richard) Date: 2003-02-07 01:08
Logged In: YES 
user_id=6405

OK, you've convinced me. I used to have "ago" in there, and it won't kill us 
to have it again. 
 
msg630 Author: [hidden] (anonymous) Date: 2003-02-07 02:19
Logged In: NO 

If the _() is for internationalization,
it would probably be better to have
two internationalized forms, one
for the future and one for the past.

In English, the strings would be
"in %s" and "%s ago".  Or
"%s from now" and "%s ago", etc.
msg631 Author: [hidden] (richard) Date: 2003-02-07 02:40
Logged In: YES 
user_id=6405

Good point, done. 
History
Date User Action Args
2003-02-02 22:34:42lukeoppermancreate