One and a half hours is not one hour and fifty minutes
A remote team receives a work record showing “1,50”. One colleague reads it as one and a half hours. Another types it into an hours-and-minutes field as 1:50. A third rounds each short entry before adding the daily total. Everybody believes they are copying the same time, but the receiving figures no longer describe the same work.
The example here is a fictional project-effort register, not payroll, billing or legal working-time advice. It illustrates why an operational handoff needs a unit and an interpretation, even when no time-zone conversion is involved.
Name three different kinds of time
A duration describes how long something took. A scheduled instant identifies a point on a timeline. A local clock reading describes the wall time in a particular place and, when necessary, a particular date. A bare “1:30” could be a duration or a clock reading, so the field label and data model must settle the meaning.
For the effort register, the approved basis is whole minutes. A 90-minute task can be displayed as 1 hour 30 minutes or as 1.5 decimal hours. If a Polish-facing decimal display uses a comma, “1,5 h” can communicate that decimal amount. It does not mean one hour and five minutes. Likewise, 1.50 decimal hours is 90 minutes; 1 hour 50 minutes is 110 minutes.
This twenty-minute difference is a unit error. Changing a Warsaw time-zone setting cannot repair it. Diagnose the meaning of the field before investigating clocks.
Follow a small worked register
The fictional day has tasks of 20, 35 and 35 minutes. Their exact total is 90 minutes, or 1.5 hours. An export that rounds every task to one decimal hour would produce 0.3, 0.6 and 0.6 hours, whose sum happens to be 1.5. That agreement is accidental and insufficient evidence of a sound rule.
Try three 20-minute tasks instead. The underlying total is 60 minutes. Rounding each task to 0.3 hours and adding the displayed values gives 0.9 hours, or 54 minutes. Adding the source minutes first and displaying the total gives 1.0 hour. Neither calculation should silently become a commercial policy; the organisation must approve where rounding occurs for the actual task.
A reliable review records the source amount, conversion and rounding decision. If the receiving software requires decimal hours, agree the precision and representation it accepts. If it can receive minutes, preserving the integer source can avoid unnecessary intermediate rounding.
Make input and export equally explicit
The input label could ask for “Duration in minutes” or provide separate labelled hours and minutes fields. An interface accepting decimal hours should explain that basis and give an ordinary example. Do not rely on a placeholder alone, because it can disappear once the person enters a value.
Browser number controls, locale settings and pasted text need actual inspection in the intended environment. A comma used in a visible example is not proof that every control or receiving parser accepts it. Server-side validation and an intelligible error remain necessary in the implemented application.
An export specification should name the unit, decimal syntax, precision and treatment of empty values. Zero minutes is different from a missing entry. Importing an empty field as zero can make incomplete work appear accounted for. A reviewer should be able to distinguish both states.
Keep meeting arrangements separate
When the same project also schedules a review between Poland and the United States, use a dated meeting time and the relevant named time zones. Do not apply an assumed permanent offset. The schedule is a separate record from the effort duration, even if both appear in the same project screen.
For acceptance, exchange a 90-minute task, three 20-minute tasks, a zero entry, a missing entry and an invalid minute component. Inspect the stored source and the imported result, not just a formatted total. Record the actual runtime and receiving tool used for the check.
The useful result is an agreed interpretation that survives the handoff. It can be a small correction to an existing report rather than a new time-tracking platform. Integration planning can establish the receiving contract, and support planning can identify who investigates a future mismatch.