Skip to content
Hours & minutes vs decimal hours

Hours & minutes vs decimal hours

mTime shows working time as hours and minutes7h30, 7:30 — rather than as decimal hours7,5, 7.5. This is the format we recommend, and it is the default for every new user. If you are coming from a system that used decimal hours, this page explains why we made that choice and how you can still switch the display for yourself.

The short version: people understand minutes, and minutes always add up. Decimal hours look tidy but hide small rounding errors, and most people can’t picture what 0,4 hours actually means.

Why we recommend hours & minutes

People think in minutes, not in tenths of an hour

Ask someone how long their meeting was and they’ll say “an hour and a half” or “forty minutes” — never “1,5 hours” or “0,67 hours”. Everyone knows how long 20 minutes feels. Almost nobody can picture 0,33 hours.

That gap matters when people register their own time. If the timesheet asks for decimal hours and someone types 1,6 because it looks about right, the value is a guess — they meant “about an hour and a half”, which is really 1h30 (1,5), not 1,6 (1h36). Registering in hours and minutes removes the guesswork: you enter the time you actually mean.

Minutes always add up — decimal hours don’t

Three tasks of 20 minutes each is exactly one hour. But written as decimal hours, 20 minutes rounds to 0,33, and:

0,33 + 0,33 + 0,33 = 0,99 — not 1,00

The minute is exact; the decimal is a rounded approximation. Do this across a week or a whole team and the small errors pile up into totals that don’t match. mTime avoids this entirely by keeping minutes as its internal unit for every calculation — worked time, expected time, flex balances, and reports are all computed in whole minutes and only converted to a display format at the very end. Twenty plus twenty plus twenty is always sixty.

Clock times are already measured in minutes

When you clock in and out, mTime records the time to the minute — not to the second. We deliberately don’t track seconds: nobody registers “3 minutes and 40 seconds” of work, and pretending to that precision would be false. Since the raw data is in minutes, keeping minutes as the unit all the way through means no rounding step ever has to happen. Decimal hours would force a conversion — and a conversion is exactly where rounding errors creep in.

It’s a personal display preference

The format is only about how time is shown to you. It changes nothing about the data underneath — everyone in your workspace is working with the same exact minute values, whether they see 7h30 or 7,5. Switching format is safe and reversible, and it affects only your own screen.

To change it:

  1. Click your profile picture or name in the bottom-left corner
  2. Select Preferences
  3. In the Formatting section, choose a Timesheet Hour Format
Timesheet Hour Format setting in Preferences
Timesheet Hour Format setting in Preferences

The dropdown previews the same duration in each style. Notice that 5h25 becomes 5,42 in decimal — a good illustration of why decimal is hard to read at a glance. You can pick from four styles — two show hours and minutes, two show decimal hours:

FormatExample (7h30)Type
7h30hours + h + minutesHours & minutes (recommended)
7:30hours : minutesHours & minutes
7,5decimal with a commaDecimal hours
7.5decimal with a dotDecimal hours

We keep the decimal options for people who genuinely prefer them or who came from mTime 5 and are used to reading time that way. But if you’re setting up a workspace for the first time, we suggest leaving everyone on hours and minutes.

A note for administrators: work time norms

When you define an employee’s expected working time — the work time norm and its distribution across the days of the week — mTime always stores it in exact minutes. You can type a value in decimal hours if that’s what you have on paper (for example 37,5 becomes 37:30), and mTime converts it to minutes for you. But the stored day is the minutes, not the decimal.

This is where decimal hours cause the most confusion. A contract that says “7,11 hours per day” looks precise, but 7,11 hours is 7h 6min 36sec — and mTime doesn’t track seconds. There is no sensible way to work a day of 7,11 hours if the smallest unit you register is the minute. Defining the day as 7h06 or 7h07 is honest about what people will actually do.

Because of this, the norm editor shows values in exact hours and minutes and adds a small * next to any decimal figure that had to be rounded, with the reminder:

* Decimal hours are approximate; hours and minutes are exact.

Rule of thumb: define norms in whole minutes (7h30, 7h24), not in decimal hours. If a decimal doesn’t land on a clean minute, mTime will flag it as approximate — that flag is telling you the number can’t be worked exactly as written.

In short

  • Give people a unit they understand. Nobody has to work out what 0,4 hours means — they work 24 minutes.
  • Totals always reconcile, because every calculation happens in whole minutes.
  • The display is yours to choose, but hours and minutes is the accurate, recommended default.