Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remaining time to download is negative #1963

Closed
ppisar opened this issue Dec 18, 2024 · 1 comment · Fixed by #1971
Closed

Remaining time to download is negative #1963

ppisar opened this issue Dec 18, 2024 · 1 comment · Fixed by #1971
Labels
bug Originally reported in Jira or Bugzilla Priority: LOW Triaged Someone on the DNF 5 team has read the issue and determined the next steps to take

Comments

@ppisar
Copy link
Contributor

ppisar commented Dec 18, 2024

A dowload progressbar reports time remaining to finishing the download. An example:

# dnf --setopt=optional_metadata_types=filelists makecache --refresh
Updating and loading repositories:
 Fedora 42 on Koji                          1% [                  ] |   4.9 KiB/s | 854.1 KiB | -03h18m

Observe negative value "-03h18m" value in the last column. In my opinion, the time should be counted from a positive value to zero.

Downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=2332931

@ppisar ppisar added Priority: LOW bug Originally reported in Jira or Bugzilla Triaged Someone on the DNF 5 team has read the issue and determined the next steps to take labels Dec 18, 2024
evan-goode added a commit to evan-goode/dnf5 that referenced this issue Dec 20, 2024
Currently, the time estimates in our progress bars are displayed as negative numbers, e.g:
Fedora 42 on Koji                          1% [                  ] |   4.9 KiB/s | 854.1 KiB | -03h18m

This formatting makes sense if the user reads it as "the current time is
T minus 3h18m", where T is the time my download will be done. And this
is the convention in some contexts, e.g. rocket launches. But it is not
idiomatic here, where a user is likely to expect the number to mean
"time remaining".

Resolves https://bugzilla.redhat.com/show_bug.cgi?id=2332931
Resolves rpm-software-management#1963
@evan-goode
Copy link
Member

I agree that negative remaining time is unidiomatic and we should change it. It was implemented intentionally:

/// Display time in one of the following formats: MMmSSs / HHhMMm / DDdHHh
/// The explicit 'negative' argument allows displaying '-00m00s'.
std::string format_time(int64_t num, bool negative) {

I filed #1971. format_time(..., negative=true) does not seem to occur anywhere else.

github-merge-queue bot pushed a commit that referenced this issue Jan 2, 2025
Currently, the time estimates in our progress bars are displayed as negative numbers, e.g:
Fedora 42 on Koji                          1% [                  ] |   4.9 KiB/s | 854.1 KiB | -03h18m

This formatting makes sense if the user reads it as "the current time is
T minus 3h18m", where T is the time my download will be done. And this
is the convention in some contexts, e.g. rocket launches. But it is not
idiomatic here, where a user is likely to expect the number to mean
"time remaining".

Resolves https://bugzilla.redhat.com/show_bug.cgi?id=2332931
Resolves #1963
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Originally reported in Jira or Bugzilla Priority: LOW Triaged Someone on the DNF 5 team has read the issue and determined the next steps to take
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants