When a user executes any prolonged task, including downloading large files or copying many files, an interface such as the one below is typically displayed to keep the user informed of the progress.

Copying files on Windows

These progress interfaces are quite ubiquitous, yet I can't help but see one inconsistency: Their time expressions.

In the screenshot above, Windows displays the estimated time left to "About 4 minutes", however I usually see just "4 Minutes" or "ETA 4 mins".

Does that mean there is less than 4 minutes left? (i.e. the estimate is rounded up) That would make the full time remaining be something like 3 minutes and 40 seconds. Or, is the estimate rounded down, meaning there is actually more than 4 minutes remaining?

What is the correct way of representing these shortened time expressions? Should what is displayed to the user be rounded up, or rounded down, and why?

  • 3
    In this case I think under-estimating has a greater chance of user frustration than over-estimating the time it will take.
    – Ben Brocka
    Jul 15, 2012 at 14:04
  • I agree with Ben, in this case (not all) it is better to under promise and over deliver. I would suggest rounding up within reason.
    – Ben
    Jul 16, 2012 at 12:54
  • +1 I like this question, it got me thinking on those X minutes until bus/train leaves/arrives/passes the platform signs, which way they work and their implications for stressed-out commuters ;) Jul 17, 2012 at 15:16

2 Answers 2


Windows and Mac handle it differently. Mac will round-DOWN. So if it says "about 3 minutes", it really means anywhere from 3:00-4:00 minutes.

On the other hand, on Windows 7, when it says "about 3 minutes", it means anywhere from 2:30-3:00 minutes. (Note that Windows provides 30 second increments)

The only time when Windows 7 rounds down is when it says "about 60 seconds".

I did some testing to figure about what they really mean by "about" and here are the results


download bmml source – Wireframes created with Balsamiq Mockups

Once you get down to under 1 minute mark, both systems provide reasonably accurate estimate. But the two takeaways from the table is:

  1. If possible, provide 30 second increments
  2. Round-up, instead of round-down

(Note: On Windows 7, you get an unusually short "About 2 Minutes" reading that lasts only 20 seconds)

  • +1, How did you go about to test this?
    – JOG
    Jul 17, 2012 at 14:42
  • @JOG I performed 3 rounds of file-copy tests on each Mac and PC each using files of varying sizes and numbers. One of the sets was over-the-LAN copy.
    – Jung Lee
    Jul 17, 2012 at 14:56
  • But how do you know the time that it is rounded FROM? The time remaining is just an estimation that is rounded. It might as well be the estimation that is under- or over-estimating, as I see it?
    – JOG
    Jul 17, 2012 at 15:00
  • @JOG Let's say, shortly after copy operation begins, status shows "About 4 minutes remaining". The moment the status changes to "About 3 minutes", I start my stopwatch and the real measurements begin. Every time the status changes, I would take note of the actual time on my stopwatch. So for each copy-operation, I would have 10-12 sets of measurements. (status vs actual). One thing to note is, both systems were very consistent and accurate in estimating. So on Mac, as soon as it says "About 3min", it took 4mins from that moment. Whereas on pc, it took 3mins, give or take 5-10 seconds.
    – Jung Lee
    Jul 17, 2012 at 15:50

Most times are rounded up, but I've seen interfaces where the time display changes (usually increasing). This really upsets most people.

I have two suggestions:

Display an accurate time remaining only if your application is also accurate and able to deliver the action in the exact time limit.


Round the time display up, informing the user that this value is approximate.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.