Bug 23501 - If minutes >= 60, then displays 01:60:00, say
Summary: If minutes >= 60, then displays 01:60:00, say
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: up2date (Show other bugs)
(Show other bugs)
Version: 7.0
Hardware: i386 Linux
medium
low
Target Milestone: ---
Assignee: Preston Brown
QA Contact: Jay Turner
URL:
Whiteboard:
Keywords:
: 28157 28248 30191 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-01-07 05:32 UTC by Nils Barth
Modified: 2015-01-07 23:42 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-03-14 13:00:36 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2001:048 normal SHIPPED_LIVE New Update Agent with many fixes and enhanced functionality available 2001-04-12 04:00:00 UTC

Description Nils Barth 2001-01-07 05:32:16 UTC
When downloading packages in up2date, time fields are displayed
incorrectly, e.g., in Time Remaining, namely the minute field, which should
be displayed mod 60, is displayed raw, e.g., if there are 90 minutes and 22
seconds remaining in a download, it displays 01:90:22, instead of 01:30:22
(or 90:22).

To reproduce, try downloading a large package (e.g., glibc) over a slow
connection (e.g., a modem).

Occurs in: up2date-2.1.7-1 on i386.

Comment 1 Geoff T 2001-02-05 07:14:17 UTC
/usr/share/rhn/up2date/gui.py:361
                tstr = _("%d of %d kb transferred at %d k/sec\nPackage transfer
time: %02d:%02d:%02d (%02d:%02d:%02d remaining)") % (amount / 1024, total /
1024, bps / 1024, totalTime / (60*60), totalTime / 60, totalTime % 60, remaining
/ (60*60), remaining / 60, remaining % 60)

should read:
                tstr = _("%d of %d kb transferred at %d k/sec\nPackage transfer
time: %02d:%02d:%02d (%02d:%02d:%02d remaining)") % (amount / 1024, total /
1024, bps / 1024, totalTime / (60*60), (totalTime % 60*60) / 60, totalTime % 60,
remaining / (60*60), (remaining % 60*60) / 60, remaining % 60)


Comment 2 Geoff T 2001-02-05 23:24:10 UTC
Sorry, I should know better than to edit code in a comment window when I should
already have gone home for the day *sighs*.  The change should read (in order to
avoid problems with evaluation order):

/usr/share/rhn/up2date/gui.py:361
                tstr = _("%d of %d kb transferred at %d k/sec\nPackage transfer
time: %02d:%02d:%02d (%02d:%02d:%02d remaining)") % (amount / 1024, total /1024,
bps / 1024, totalTime / (60*60), totalTime / 60, totalTime % 60, remaining /
(60*60), remaining / 60, remaining % 60)

should read:
                tstr = _("%d of %d kb transferred at %d k/sec\nPackage transfer
time: %02d:%02d:%02d (%02d:%02d:%02d remaining)") % (amount / 1024, total /
1024, bps / 1024, totalTime / (60*60), (totalTime % 3600) / 60, totalTime % 60,
remaining / (60*60), (remaining % 3600) / 60, remaining % 60)

Comment 3 Adrian Likins 2001-02-08 05:37:51 UTC
Cool. Will make the change. Should be in the next up2date release.

Comment 4 Adrian Likins 2001-02-18 04:55:20 UTC
*** Bug 28157 has been marked as a duplicate of this bug. ***

Comment 5 Cristian Gafton 2001-02-20 01:32:51 UTC
Assigned QA to jturner

Comment 6 Preston Brown 2001-03-06 05:25:13 UTC
fixed in CVS.

Comment 7 Preston Brown 2001-03-06 05:30:44 UTC
*** Bug 28248 has been marked as a duplicate of this bug. ***

Comment 8 Preston Brown 2001-03-06 05:33:28 UTC
*** Bug 30191 has been marked as a duplicate of this bug. ***

Comment 9 Jay Turner 2001-03-07 14:00:30 UTC
I am still seeing this problem with the 3/7/01 CVS code over dial-up.

Comment 10 Jay Turner 2001-03-14 13:00:27 UTC
OK, testing in the 3/14 tree shows that this problems appears to be solved.  We
are getting valid estimates for the time for transfer, so that's a good thing. 
I will test this evening with dial-up and make sure that we are displaying
minutes and hours correctly.

Comment 11 Preston Brown 2001-04-12 20:58:50 UTC
addressed in errata due out today.


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