BlogData

A pint needs a measurement system

US liquid pints and imperial pints have different volumes. Resolve the definition before converting, and use returned choices when context is missing.

"1 pint" gives a converter a number and a unit name. It still leaves a question: which pint? A US liquid pint and an imperial pint represent different volumes. NIST's conversion tables distinguish US and imperial volume definitions. Treating the names as interchangeable changes the quantity.

The Measure API leaves that choice open when the input does not settle it:

GET /measure/1%20pint?to=mL

This returns HTTP 200 with valid: false. The input is recognizable, but ambiguous. Here is the relevant response excerpt:

{
  "measure": "1 pint",
  "valid": false,
  "amount": null,
  "unit": null,
  "reason": "ambiguous_unit",
  "choices": [
    { "unit": "pt_us", "name": "US pint" },
    { "unit": "pt_imp", "name": "imperial pint" }
  ]
}

For this supported unit, pt_us means the US liquid pint. The choices give your form something concrete to ask: US pint or imperial pint? A parser failure does not have to become a generic red error when it can identify the missing decision.

When the source context already establishes the measurement system, supply it explicitly:

GET /measure/1%20pint?system=us&to=mL
GET /measure/1%20pint?system=imperial&to=mL

The first returns amount: "473.176473" and unit: "mL". The second returns amount: "568.26125" with the same target unit. These are decimal strings, as are other converted amounts. The target stays the same. The source definition is what changes.

You can also remove the ambiguity in the measurement itself. /measure/1%20pt_us?to=mL names the definition directly. Explicit unit codes retain their meaning even if a different system is supplied. system=imperial does not reinterpret pt_us as an imperial pint.

Number format is a separate setting

locale tells the parser how to read decimal and grouping separators. system resolves supported customary unit names that have competing definitions. Setting locale=en-US does not select the US pint. Neither setting is inferred from a browser, an IP address, or an account preference.

For an import, use the unit definition recorded by the source. A supplier's documented US liquid units can justify system=us. The country of whoever happens to upload the file cannot. If the source gives only "pint" without enough context, keep the row unresolved and ask for that context.

Once a choice is made, preserve it with the original measurement and converted result. A saved pt_us is specific enough to convert again later. A saved label of "pint" reopens the same question. The unit catalog describes discovery for the supported codes and names, so an application can offer defined choices before it needs to calculate anything.