Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Unexpected result converting to canonical type

Open
#21 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
45/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Tech stack
java
Domain
backend

Research direction

Reproduce the issue with the Java snippet in the report and trace convert() through the canonical [m] to destination [m] path. Inspect the identity conversion that uses Decimal("1", precision=1); done means converting 1[mi_i] to [m] preserves 1609.344 rather than rounding it to 1609.

Written by the indexing model from the issue text.

Description

    Decimal m = ucum.convert(new Decimal("1",15), "[mi_i]","m");
    System.out.println("one mile = " + m + "m expect 1609.344");

Internally convert() first correctly converts 1[mi_i] to canonical unit [m] as 1609.344 but the
conversion from canonical [m] to destination type [m] converts 1609.344 to 1609 because
the identity conversion m->m uses Decimal("1",precision=1)

I would expect the unity conversion to be a noop.

Dominant language
Java
Stars
26
Forks
18
PR merge metrics
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from FHIR/Ucum-java

All issues in FHIR/Ucum-java

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.