In an app that measures timespans, I want to express the overall value in a human-readable form.

Let's say we are measuring the time a machine runs, idles, is in standby or off.

The times are measured and easily combined. I want to give quick human-readable information like:

The Machine has been running for 10 months, 2 two weeks, 1 day, 3 hours ...

I know there is no correct way (ok, one could go with one-twelfth of 365.25 days) but that seems nonsensical.

Approximating a month to 30 days is one solution that seems understandable and 30 is a nice round number, and mathematically rounded from actually 30.4 days it would be somewhat correct.

Going with 28 days has the benefit that it covers even the shortest month and what I like most about this is, that is exactly 4 weeks. Also, the lunar month is usually considered to be 28 days.

Which way to count would be understood better by users?

2 Answers 2


Let's say we are measuring the time a machine runs, idles, is in standby or off.

I think it depends more on the smallest amount that you want to convey. You want the user to easily compare run, idle, and standby.

If runtime is 10 months, and idle time is 1 day, and standby is 3 hours, that not a comparison someone can quickly make in their head.

So you could use hours: 7300, 24, and 3, but still not ideal.

Or, you could normalize to the timeframe, and say, over the last 10 months, idle time was 0.33%, and standby was 0.04%.

Since percentage is a dimensionless measurement, it allows easy comparisons between different time ranges, different manufacturing plants, etc.

  • Thanks, interesting point you make. As I mentioned in an other comment it is hard to describe the use cases in ore detail now, but I imagine that looking at the data of one machine is the starting point for my research. One rather important point would be to get a rough estimate of usage also for service intervals etc. For the very good use case you describe we will have to (and will) provide detailed comparison and analysis charts. The 'human readable' part ist actually that what I'm mostly interested, and very few people have a concept of the timespan described by 3000 hours. Sep 15 at 18:18

This is a question that needs more info about the purpose of the app in order to determine the best design. I think it depends how accurate you need to be. Since everything is consistent up until month (week always has 7 days, 1 day always has 24 hours, etc.), you could consider removing the months with the highest point being weeks. So you could have like 12 weeks instead of converting the weeks to months. If you dont need to be 100% accurate, I think having the months be 30 days is clear/consistent enough for the user.

  • Thanks for your answer. Accuracy isn't My main concern for that part, and as we are in the early stages of defining the design requirements it's hard to give amore detailed description. There will likely be an option to have several machines of one type, so that even after only some month the combines runtime will be one or several years, and some how showing 2 years; 45 weeks; 5 days... seems not the best solution. Sep 15 at 17:28
  • Since its a combined runtime rather than time elapsed, have you considered just doing hours/mins? Given the information, expanding into days/months would be confusing because you could accomplish 1 day in less than 1 day real time. Hours/mins can be combined and easily understood, but adding days/months you are going beyond a "clock" into a "calendar" type elapsed time. I would be confused if the total runtime of 3 machines said 1 day runtime when only 8 hours passed (8 hours x3 machines) while saying 24 hours runtime makes sense to me no matter how much time has passed in real life.
    – Gene Lee
    Sep 15 at 17:56

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.