One device sends 68°F; another field reports a temperature rise of 18°F. The first corresponds to 20°C, the second to a 10°C difference. Subtracting 32 and dividing by 1.8 in both cases turns the second result into approximately −7.78 and misrepresents warming as cooling. The issue is whether a field represents a temperature state or a difference between states. These are constructed examples for data platforms and feature engineering, not site experiments or a control-system safety design.
Preserve the quantity's meaning before resampling
Industrial sensor resampling and missing-data handling requires explicit bucket, coverage and filling rules. Unit conversion belongs at an earlier semantic boundary: correct time alignment cannot repair Fahrenheit values interpreted as Celsius. Establish the meaning of each original observation before aggregation, interpolation or model calculation.
Retain the measurement point, device and channel, original value, original unit, quantity role, event time, quality code and source version. Roles should at least distinguish temperature readings, differences, rates of change and error or tolerance magnitudes. A value column and a unit column alone are usually insufficient to determine every operation.
For example, 5°C could be a current temperature or a rise relative to a reference. Signs do not resolve the ambiguity because readings and differences can both be negative. Obtain meaning from the interface contract, measurement configuration or device protocol. Quarantine an unspecified role instead of allowing a language model to infer it from a field name.
Keep a traceable original layer and store canonical values, canonical units, conversion versions and processing states separately. Originals enable recomputation after a mapping correction and identification of affected alerts, reports and training features.
Readings require offsets; differences require scaling
NIST's exact conversion table defines Celsius readings as Fahrenheit readings minus 32, divided by 1.8, and kelvin readings as Celsius readings plus 273.15.[1] A temperature-reading conversion therefore generally has the form y = a×x + b rather than multiplication by one factor.
A second NIST resource states that temperature intervals can be expressed in kelvins or degrees Celsius, with equal interval magnitude.[2] Subtracting two readings under the same transformation cancels the offset: Δy = a×Δx. Fahrenheit differences convert to Celsius differences by division by 1.8 alone; Celsius differences convert to kelvin differences without adding 273.15.
The temperature component of a rate is also a difference. A rise of 18°F per minute is 10°C per minute, or approximately 0.1667 K per second. This also converts the time denominator. Treating 18 as a Fahrenheit reading, or ignoring the change from minutes to seconds, gives the wrong quantity.
Pint 0.25 distinguishes offset temperature units from delta units and rejects several ambiguous offset-unit operations by default.[3] Such protection is not a business-semantic inference engine. If an application wrongly declares a rise as a reading, the library may faithfully execute the wrong request. This article cites fixed-version behavior; it does not report running Pint or assume identical behavior across all versions.
Constructed records require different processing paths
Consider A, an inlet reading of 68°F; B, an outlet reading of 86°F; C, a device-reported rise of 18°F; and D, a reading of 20 with no unit. A and B are readings and become 20°C and 30°C. C is a difference and becomes 10 K. D must retain an unknown-unit state.
If A and B concern comparable measurement points and times in the same process, B−A should be 10 K and can be reconciled with C. This check has prerequisites: the device may define its rise against another reference or sample at another time. Equal numbers do not prove equal measurement meaning.
Add E: a current reading of 20°C with tolerance ±2°C. Its canonical reading is 293.15 K and its tolerance magnitude remains 2 K. If instead represented as interval endpoints of 18°C and 22°C, those endpoints become 291.15 K and 295.15 K. Magnitudes and endpoints need distinct field roles.
Acceptance should preserve D's quarantine state. A plausible room-temperature value does not justify assuming Celsius. If one source protocol explicitly defines an omitted unit as Celsius, retain that source rule and its effective version in the mapping instead of extending it to all equipment.
On replay, identify the input layer and original record so a canonical Celsius value cannot be converted again as Fahrenheit. An output column name alone is inadequate evidence of processing state. Canonical records need a version, and reruns should generate new results from the original layer.
Means, sums and ratios have different semantic requirements
For the same quantity and definition, an affine conversion commutes with a weighted mean whose weights sum to one. The equal-weight mean of 20°C and 30°C is 25°C, equivalent to 298.15 K. This algebra does not establish that averaging unrelated measurement points is useful.
If one record is 68°F and another 30°C, averaging the bare numbers to 49 and labeling the result Celsius is wrong. Convert each reading to a common scale first and preserve the weights to obtain 25°C. Missing or invalid observations still require an independent denominator policy.
Sums do not enjoy the same property. Summing n individually converted readings includes n offsets; converting the raw sum as one reading includes only one. Temperature is also generally not an additive business total across measurement points. Heat or mixing calculations need quantities such as mass, heat capacity and process assumptions, rather than a simple sum of temperatures.
Saying that 40°C is twice 20°C divides Celsius scale numbers; it does not establish a doubling of thermodynamic temperature. If the physical question calls for an absolute-temperature ratio, use kelvins and establish that the comparison is meaningful. Process deviation more often calls for a difference from a specified baseline and a threshold than an arbitrary scale-based growth rate.
Under simple linear scale changes, standard deviations and error magnitudes scale by the absolute factor without an offset; variances scale by its square. Measurement uncertainty involving calibration parameters, correlated errors or nonlinear processing requires more than unit conversion. The scope here is converting existing quantities, not evaluating instrument precision.
Implement controlled mappings and versioned outputs
First define source-field mappings with quantity role, allowed units, canonical unit, parsing policy and effective period. Canonical readings may use K or explicitly defined °C, while differences can use K with a retained role field. One storage convention is easier to maintain than inferring semantics from inconsistent column suffixes.
Second check semantics and quality. Preserve distinct causes for unknown units, unknown roles, invalid quality codes and unparseable text; do not replace them all with zero. Control aliases such as degC and °C. Whether a lone C is allowed should depend on the source contract, not a platform-wide substitution.
Third dispatch conversion by role, retain adequate calculation precision and round for presentation under an agreed rule. Convert 68°F to 20°C before presentation rounding instead of rounding repeatedly across intermediate stages. Exact conversion constants do not confer unlimited precision on measurements, and additional displayed decimals do not make an instrument more accurate.
Fourth apply measurement-specific plausibility and relationship checks: allowed range, rise direction and maximum rate of change. One room-temperature range cannot cover every process. Out-of-range data need a traceable state; the task's quality contract should decide downstream use rather than the converter silently clipping values.
Fifth publish canonical results by version and reconcile converted counts, quarantined counts, source composition and critical event changes. Correcting a historical rise-versus-reading mapping requires an affected-record list and bounded recomputation of reports and features. Preserve previous versions to explain earlier decisions instead of erasing the evidence.
Test roles and refusal behavior with counterexamples
A fixed suite should include these expected results: a 32°F reading becomes 0°C; a 32°F difference becomes approximately 17.7778 K; an 18°F difference becomes 10 K; a 20°C reading becomes 293.15 K; a 20°C difference becomes 20 K; and a −40°F reading becomes −40°C. Use a predetermined numerical tolerance for repeating decimals rather than comparing formatted strings.
Test composition as well. Under one conversion rule, converting two readings and subtracting should match subtracting first and converting the difference. Equivalent Celsius and Fahrenheit representations of one physical record should produce the same canonical value and threshold decision. Round trips should recover the original within tolerance, but mutually incorrect forward and inverse rules can cancel, so round-trip checks cannot replace independent known values.
Negative cases must include missing units, missing roles, a rise incorrectly declared as a reading, a measurement point changing units, and canonical data incorrectly returned to the raw-input boundary. Check quarantine reasons, rule versions, source associations and protection against repeated conversion as well as numerical outputs.
Finally replay a small historical segment with trustworthy human references and compare threshold events and features. This is a proposed acceptance design with hand-checkable examples, not a deployment result. Correct units are one layer of trustworthy industrial data; measurement location, time alignment, calibration status and operating conditions still require separate verification. A conversion library cannot supply those facts.