Bug 1253849 - RFE: Time values table of builds are not humanized
RFE: Time values table of builds are not humanized
Status: CLOSED WONTFIX
Product: Copr
Classification: Community
Component: frontend (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity low
: ---
: ---
Assigned To: clime
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-14 18:07 EDT by Tomáš Hozza
Modified: 2016-01-28 09:54 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-28 09:44:49 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
non humanized values (82.99 KB, image/png)
2015-08-14 18:07 EDT, Tomáš Hozza
no flags Details

  None (edit)
Description Tomáš Hozza 2015-08-14 18:07:22 EDT
Created attachment 1063174 [details]
non humanized values

Description of problem:
There are sometimes wired time values in the COPR Web UI, like that build was submitted "30 hours ago" instead of "1 day ago" or "69 minutes ago" instead of "1 hour ago"

Please see the attached screenshot.

The values should be ideally humanized.
Comment 1 Jens Petersen 2015-10-20 05:18:36 EDT
For submissions that are not very recent I would prefer have date and time stamp actually - I don't particularly like information hiding here.

ie I might also want to see which of two builds finished first witout having to resort to sorting by build time.
Comment 2 clime 2016-01-28 09:32:51 EST
The logic goes like this:
Comment 3 clime 2016-01-28 09:34:15 EST
    diff = now - datetime.datetime.fromtimestamp(time_in)
    secdiff = int(diff.total_seconds())
    if secdiff < 120:
        # less than 2 minutes
        return "1 minute"
    elif secdiff < 7200:
        # less than 2 hours
        return str(secdiff // 60) + " minutes"
    elif secdiff < 172800:
        # less than 2 days
        return str(secdiff // 3600) + " hours"
    elif secdiff < 5184000:
        # less than 2 months
        return str(secdiff // 86400) + " days"
    elif secdiff < 63072000:
        # less than 2 years
        return str(secdiff // 2592000) + " months"
    else:
        # more than 2 years
        return str(secdiff // 31536000) + " days

Personally I like the two days resolution. I think it is matter of personal preference.
Comment 4 clime 2016-01-28 09:44:49 EST
Jens Petersen:
   Please, if you care about more detailed timestamp resolution, fill a separate bug with a description. To me the current state is nice and precise enough.
Comment 5 Tomáš Hozza 2016-01-28 09:52:24 EST
(In reply to clime from comment #4)
> Jens Petersen:
>    Please, if you care about more detailed timestamp resolution, fill a
> separate bug with a description. To me the current state is nice and precise
> enough.

I think this bug has a pretty self-explaining description. If the issue has been fixed - IOW there are no non-sense values like "69 minutes ago", then close it with proper comment. Saying that you like it as it is right now is hardly a technical decision.
Comment 6 Tomáš Hozza 2016-01-28 09:54:48 EST
(In reply to Tomas Hozza from comment #5)
> (In reply to clime from comment #4)
> > Jens Petersen:

Sorry, I missed that this was more a response to the comment #1. However closing this as WONTFIX does not makes sense to me.

Note You need to log in before you can comment on or make changes to this bug.