Temperatuuromrekening: Celsius, Fahrenheit, Kelvin

Je levert maandag een weerdashboard op. Woensdag meldt een gebruiker in Toronto een bug: de app toont de buitentemperatuur als 284. Het OpenWeatherMap-endpoint gaf Kelvin terug (de standaard), je UI verwachtte Celsius, en niets daartussenin had de moeite genomen om dat te controleren. Eén ontbrekende aftrekking, één kapotte screenshot op Twitter.

Als je gewoon de twee formules wilt en verder wilt gaan:

Celsius naar Fahrenheit: °F = °C × 9/5 + 32
Fahrenheit naar Celsius: °C = (°F − 32) × 5/9
Celsius naar Kelvin: K = °C + 273.15

Die drie dekken zo’n 90% van wat ontwikkelaars in de praktijk nodig hebben. De rest van deze gids gaat over de andere 10%: waar 9/5 vandaan komt, waarom Kelvin nooit negatief is, hoe je je typesysteem celsiusToFahrenheit(kelvinValue) al bij compilatie laat afwijzen, en hoe je de Toronto-bug voorkomt. Je kunt de handleiding ook volledig overslaan en onze temperatuur-omrekentool gebruiken als je gewoon een getal nodig hebt. Zie voor niet-temperatuurgerelateerde eenheden de bredere complete gids voor eenheidsomrekening.

Waarom temperatuur anders is dan andere eenheidsomrekeningen

De meeste eenheidsomrekeningen zijn op triviale wijze lineair door nul. Een meter is 3,28084 voet, punt. Verdubbel de meters, verdubbel de voet. Nul meter is nul voet. Je kunt een conversiebibliotheek bouwen met één vermenigvuldigingsconstante per paar en er nooit meer over nadenken.

Temperatuur doorbreekt dit model: de schalen hebben geen gemeenschappelijk nulpunt. Celsius verankert zijn nul aan het vriespunt van water. Fahrenheit verankert zijn nul aan een pekeloplossing uit 1724. Kelvin verankert zijn nul aan de theoretische ondergrens van de thermodynamica. Om van de ene naar de andere te gaan, heb je zowel een schaalfactor als een verschuiving nodig — temperatuur is een affiene transformatie, geen lineaire.

Dit heeft een gevaarlijk gevolg: temperatuurwaarden zijn niet additief zoals lengte- of massawaarden dat zijn. 20°C + 20°C is in geen enkele fysieke zin 40°C. Je kunt geen “twee kamers optellen” en een warmere kamer krijgen. Je kunt wel een temperatuurverschil optellen bij een temperatuur, want verschillen zijn lineair. Dat onderscheid is wat in 2006 het Medeva-vaccin-incident in het VK veroorzaakte, waarbij een farmaceutische koudeketen-logger een absolute meting verwarde met een delta en duizenden doses als buiten-spec bestempelde. Intensieve grootheden zoals temperatuur vereisen dit mentale houvast: getallen die dezelfde eenheid delen, delen niet automatisch dezelfde algebra.

De vier temperatuurschalen uitgelegd

Voor dagelijks gebruik in code zijn er maar twee schalen echt relevant (Celsius, Fahrenheit), een derde is essentieel voor wetenschappelijk werk (Kelvin), en de vierde kom je precies op één plek tegen: Amerikaanse thermodynamica-leerboeken en de HVAC-codebases die er nog naar verwijzen.

Celsius (°C)

Anders Celsius publiceerde zijn schaal in 1742, oorspronkelijk met 0° bij het kookpunt en 100° bij het vriespunt — omgekeerd aan wat we nu gebruiken. De moderne oriëntatie, met 0°C bij het vriespunt van water en 100°C bij het kookpunt onder één standaardatmosfeer, ontstond kort na zijn dood. Tegenwoordig is het de SI-afgeleide eenheid voor alledaagse temperatuur en de standaardschaal in elk land behalve de Verenigde Staten, de Bahama’s, Belize, de Kaaimaneilanden en Liberia.

De SI-herdefinitie van 2019 koppelde Celsius rigoureus aan Kelvin: 0°C is nu gedefinieerd als precies 273,15 K. Het vriespunt van water, ooit de definitie, is nu een gemeten gevolg (het valt op 0°C tot op delen per miljoen, maar is niet langer het ankerpunt).

Fahrenheit (°F)

Daniel Gabriel Fahrenheit stelde zijn schaal voor in 1724. Hij koos 0°F als het vriespunt van een specifieke pekeloplossing — de koudste temperatuur die hij betrouwbaar kon reproduceren in een winter in Danzig — en 96°F als lichaamstemperatuur. Latere herkalibratie op het vriespunt en kookpunt van zuiver water verschoof de lichaamstemperatuur naar 98,6°F, waarmee het vriespunt op 32°F en het kookpunt op 212°F kwamen te liggen, een bereik van 180 graden.

Fahrenheit overleeft in de Verenigde Staten voor weer, koken en medisch gebruik. Het bereik van 180 graden tussen vriespunt en kookpunt (versus 100 bij Celsius) wordt soms verdedigd als “fijnere resolutie voor omgevingstemperaturen” — een marginale claim, maar een die verklaart waarom Amerikaanse thermostaten per 1°F zijn ingedeeld terwijl Europese stappen van 0,5°C gebruiken.

Kelvin (K)

William Thomson, Lord Kelvin, stelde in 1848 een absolute schaal voor. De moderne kelvin is de SI-basiseenheid voor temperatuur. De SI-herdefinitie van 2019 koppelt de kelvin exact aan de Boltzmann-constante k_B = 1,380649 × 10⁻²³ J/K, waardoor het een gedefinieerde in plaats van gemeten grootheid is.

Kelvin heeft drie eigenaardigheden die ontwikkelaars moeten kennen:

Geen graaditeken. Schrijf 300 K, niet 300°K. Dit is de SI-conventie sinds 1967.
Begint bij het absolute nulpunt. 0 K = −273,15°C. Je zou nooit een negatieve Kelvin-waarde in geldige data moeten zien; beschouw die als een invoerfout.
Dezelfde graadgrootte als Celsius. Een verandering van 1 K is gelijk aan een verandering van 1°C. Temperatuurverschillen zijn uitwisselbaar tussen beide; alleen absolute waarden verschillen door de verschuiving van 273,15.

Kelvin is de juiste keuze wanneer je temperaturen vermenigvuldigt of deelt — thermische straling (T⁴), ideale gaswet, zwartlichaamsfysica. Deling door een negatieve of bijna-nul Celsius-waarde brengt de wiskunde die je wilt behouden in gevaar.

Rankine (°R)

William Rankine stelde deze schaal voor in 1859 als het Fahrenheit-equivalent van Kelvin: een absolute schaal, nul bij het absolute nulpunt, maar met Fahrenheit-grote graden. 0°R = −459.67°F. 491.67°R = 0°C.

Je komt Rankine zelden tegen buiten de Amerikaanse thermodynamische techniek — HVAC-berekeningen, aardolieraffinage, verbrandingsanalyse van raketmotoren — waar de wiskunde een absolute schaal nodig heeft maar de invoerdata in Fahrenheit aankomt. Omrekenen is mechanisch: °R = °F + 459.67, of gelijkwaardig °R = K × 9/5. De meeste moderne technische software kan intern in Kelvin werken en alleen voor weergave omzetten, wat ik aanraden als je de keuze hebt.

Omrekenformules voor temperatuur (alle zes richtingen)

Zes richtingen, vier schalen, zes formules. In de praktijk onthoud je de Celsius-gecentreerde formules en stel je de rest samen.

Celsius naar Fahrenheit en terug

°F = °C × 9/5 + 32
°C = (°F − 32) × 5/9

De factor 9/5 is de verhouding van de bereiken van beide schalen tussen dezelfde twee fysieke referentiepunten. Van vriespunt tot kookpunt beslaat Fahrenheit 180 graden (32 tot 212); Celsius beslaat 100 (0 tot 100). 180 / 100 = 9/5 = 1,8. De + 32 is de verschuiving die nodig is om de vriespunt-nullen op één lijn te brengen, omdat het nulpunt van Fahrenheit 32°F onder het nulpunt van Celsius ligt.

Rekenvoorbeeld: °F = 25 × 9/5 + 32 = 45 + 32 = 77°F.

Celsius naar Kelvin en terug

K = °C + 273.15
°C = K − 273.15

Geen schaalverdeling, alleen een verschuiving. 273.15 is de numerieke afstand van het nulpunt van Celsius (het vriespunt van water) tot het absolute nulpunt, gemeten in Celsius-graden. Omdat Kelvin en Celsius dezelfde graadgrootte delen, is er geen vermenigvuldiger.

Fahrenheit naar Kelvin en terug

K = (°F − 32) × 5/9 + 273.15
°F = (K − 273.15) × 9/5 + 32

Er is geen kortere vorm — zowel een schaalverandering als een verschuivingsverandering zijn nodig. In code is het netter om via Celsius te werken: k = cToK(fToC(f)). Je schrijft minder, vertrouwt het meer, en de compiler optimaliseert de samenstelling sowieso weg.

Rankine-omrekeningen

°R = °F + 459.67
°F = °R − 459.67
°R = K × 9/5
K  = °R × 5/9
°R = °C × 9/5 + 491.67

491.67 is 32 × 9/5 + 459.67, dat wil zeggen de Rankine-waarde die overeenkomt met 0°C. Je zult deze formules zelden in de praktijk samenstellen. Als je Rankine nodig hebt, behandel het dan als “de absolute tweeling van Fahrenheit” en werk via Fahrenheit of Kelvin.

Waar komt 9/5 vandaan? Een korte afleiding

De twee schalen zijn gerelateerd door een affiene functie °F = a × °C + b. Om a en b op te lossen, heb je twee bekende kalibratiepunten nodig. Vriespunt en kookpunt zijn het gebruikelijke paar:

Vriespunt: 0°C ↔ 32°F
Kookpunt: 100°C ↔ 212°F

Invullen in °F = a × °C + b:

32  = a × 0   + b   →  b = 32
212 = a × 100 + 32  →  a = (212 − 32) / 100 = 180 / 100 = 9/5

Dat is alles — twee lineaire vergelijkingen, twee onbekenden, en de hele omrekening volgt eruit. De geometrische intuïtie: stel je twee verticale thermometers naast elkaar voor, één in Celsius, één in Fahrenheit. De Fahrenheit-thermometer is verticaal uitgerekt (helling 9/5) en naar boven verschoven (snijpunt 32) ten opzichte van de Celsius-thermometer. Elke andere omrekenwaarde ligt op die uitgerekte en verschoven lijn.

Dezelfde afleiding met (0°C, 273,15 K) en (100°C, 373,15 K) geeft Celsius-naar-Kelvin: helling 1, snijpunt 273,15. Dezelfde afleiding met twee ondubbelzinnige kalibratiepunten geeft je elke affiene omrekening. Wiskundig is temperatuur niets bijzonders — de complexiteit zit volledig in de twee-ankerpunten-opstelling die andere eenheidstypes niet nodig hebben.

Het snijpunt bij −40°: een handig ezelsbruggetje

Is er een temperatuur waarbij Celsius en Fahrenheit hetzelfde getal tonen? Stel °C = °F in de omrekenformule:

°C = °C × 9/5 + 32
°C − °C × 9/5 = 32
°C × (1 − 9/5) = 32
°C × (−4/5) = 32
°C = −40

Dus −40°C = −40°F. Precies één kruispunt, en het is toevallig een werkelijke temperatuur die je in Yellowknife, Jakoetsk of Fairbanks in januari kunt tegenkomen. Het is ook een goedkope mentale controle: als je een C↔F-omrekening op het oog schat en het resultaat uitkomt bij −40, moeten beide getallen dicht bij elkaar liggen. Als één −40°C zegt en de andere −72°F, heb je een richtingsfout.

Ik heb de volledige lijst met ezelsbruggetjes naast mijn monitor geplakt: vriespunt (0 / 32), lichaamstemperatuur (37 / 98,6), kamertemperatuur (20 / 68), kookpunt (100 / 212), −40 (−40 / −40). Vijf punten dekken bijna elke snelheidscontrole die ik nodig heb.

Temperatuuromrekening in code

De formules zijn eenvoudig. Ze goed toepassen in een echte codebase draait om twee dingen: voorkomen dat een aanroeper Fahrenheit doorgeeft waar je Celsius verwachtte, en het zwevendekommagedrag voorspelbaar maken aan de grenzen (vriespunt, absoluut nulpunt, oventemperaturen). Elk voorbeeld hieronder is een volledig, uitvoerbaar programma.

JavaScript / TypeScript

Gewoon JavaScript geeft je direct functionele omrekeningen:

const cToF = (c) => c * 9 / 5 + 32;
const fToC = (f) => (f - 32) * 5 / 9;
const cToK = (c) => c + 273.15;
const kToC = (k) => k - 273.15;
const fToK = (f) => cToK(fToC(f));
const kToF = (k) => cToF(kToC(k));
const cToR = (c) => (c + 273.15) * 9 / 5;
const rToC = (r) => r * 5 / 9 - 273.15;

console.log(cToF(100));   // 212
console.log(fToC(98.6));  // 37
console.log(kToC(300));   // 26.85

Met TypeScript maak je eenheidsverwarring een compile-time fout door het getal-type te branden:

type Scale = 'C' | 'F' | 'K' | 'R';
type Temp<S extends Scale> = number & { readonly __scale: S };

const t = <S extends Scale>(value: number, _scale: S): Temp<S> =>
  value as Temp<S>;

const cToF = (c: Temp<'C'>): Temp<'F'> => t(c * 9 / 5 + 32, 'F');
const fToC = (f: Temp<'F'>): Temp<'C'> => t((f - 32) * 5 / 9, 'C');

const indoor = t(22, 'C');
const outdoor = cToF(indoor);   // OK: Temp<'F'>
// const broken = cToF(outdoor); // Compile error: Temp<'F'> is not Temp<'C'>

Branded types hebben nul runtime-kosten en kosten je maar een tiental regels boilerplate. In ruil daarvoor verschijnt de Toronto-bug uit de inleiding als rode kringel in je editor.

Python

Gewone functies werken prima, maar een Enum plus dataclass verdient zichzelf terug de eerste keer dat je een temperatuur logt:

from dataclasses import dataclass
from enum import Enum

class Scale(Enum):
    C = "°C"
    F = "°F"
    K = "K"
    R = "°R"

@dataclass(frozen=True)
class Temperature:
    value: float
    scale: Scale

    def to(self, target: Scale) -> "Temperature":
        c = _to_celsius(self)
        return _from_celsius(c, target)

    def __str__(self) -> str:
        return f"{self.value:.2f}{self.scale.value}"

def _to_celsius(t: Temperature) -> float:
    if t.scale is Scale.C: return t.value
    if t.scale is Scale.F: return (t.value - 32) * 5 / 9
    if t.scale is Scale.K: return t.value - 273.15
    if t.scale is Scale.R: return (t.value - 491.67) * 5 / 9
    raise ValueError(f"Unknown scale: {t.scale}")

def _from_celsius(c: float, scale: Scale) -> Temperature:
    if scale is Scale.C: return Temperature(c, scale)
    if scale is Scale.F: return Temperature(c * 9 / 5 + 32, scale)
    if scale is Scale.K: return Temperature(c + 273.15, scale)
    if scale is Scale.R: return Temperature(c * 9 / 5 + 491.67, scale)
    raise ValueError(f"Unknown scale: {scale}")

body = Temperature(37, Scale.C)
print(body.to(Scale.F))   # 98.60°F
print(body.to(Scale.K))   # 310.15K

Als je wetenschappelijke data verwerkt waarbij 0.1 + 0.2 != 0.3 een auditprobleem wordt, vervang float dan door decimal.Decimal. De afweging is snelheid (Decimal is ruwweg 50× trager) en het feit dat 5/9 ook geen exacte decimale representatie heeft, zodat je Decimal(5) / Decimal(9) met een gecontroleerde context nodig hebt. Voor de meeste sensor-pipelines is float plus round(value, 2) aan de weergavegrens voldoende.

Go

Go’s typesysteem laat je verder gaan dan TypeScript: een benoemd float64-type kan niet stilzwijgend worden gemengd met een ander benoemd float64-type, ook al delen ze dezelfde runtime-representatie.

package main

import "fmt"

type Celsius float64
type Fahrenheit float64
type Kelvin float64
type Rankine float64

func (c Celsius) ToFahrenheit() Fahrenheit { return Fahrenheit(c*9/5 + 32) }
func (c Celsius) ToKelvin() Kelvin         { return Kelvin(c + 273.15) }
func (f Fahrenheit) ToCelsius() Celsius    { return Celsius((f - 32) * 5 / 9) }
func (k Kelvin) ToCelsius() Celsius        { return Celsius(k - 273.15) }
func (f Fahrenheit) ToKelvin() Kelvin      { return f.ToCelsius().ToKelvin() }

func main() {
    room := Celsius(22)
    fmt.Printf("%.2f °F\n", room.ToFahrenheit()) // 71.60 °F
    fmt.Printf("%.2f K\n", room.ToKelvin())      // 295.15 K

    // var bug Fahrenheit = room          // compile error
    // fmt.Println(room.ToKelvin() + 1)   // compile error: Kelvin + untyped int needs Kelvin(1)
}

De kosten zijn ruwweg één regel per schaal. Het voordeel is dat ToFahrenheit per ongeluk geen Kelvin-waarde kan aannemen, en een functie die Celsius verwacht een kale float64 op de aanroeplocatie weigert.

Rust

Het newtype-patroon van Rust geeft je dezelfde garanties als Go, plus goedkope From/Into-omrekeningen:

#[derive(Clone, Copy, Debug, PartialEq)]
struct Celsius(f64);

#[derive(Clone, Copy, Debug, PartialEq)]
struct Fahrenheit(f64);

#[derive(Clone, Copy, Debug, PartialEq)]
struct Kelvin(f64);

impl From<Celsius> for Fahrenheit {
    fn from(c: Celsius) -> Self { Fahrenheit(c.0 * 9.0 / 5.0 + 32.0) }
}

impl From<Fahrenheit> for Celsius {
    fn from(f: Fahrenheit) -> Self { Celsius((f.0 - 32.0) * 5.0 / 9.0) }
}

impl From<Celsius> for Kelvin {
    fn from(c: Celsius) -> Self { Kelvin(c.0 + 273.15) }
}

impl From<Kelvin> for Celsius {
    fn from(k: Kelvin) -> Self { Celsius(k.0 - 273.15) }
}

fn main() {
    let body = Celsius(37.0);
    let body_f: Fahrenheit = body.into();
    let body_k: Kelvin = body.into();
    println!("{:.2} {:?} {:?}", body.0, body_f, body_k);
    // 37.00 Fahrenheit(98.6) Kelvin(310.15)
}

Je kunt er validatie bovenop leggen: een TryFrom<f64> for Kelvin die negatieve waarden afwijst geeft Result<Kelvin, TemperatureError> terug en verschuift de controle naar constructietijd. Ongeldige toestanden bereiken je bedrijfslogica nooit.

SQL (PostgreSQL)

Sla temperaturen op met CHECK-beperkingen en leid alternatieve eenheden af als gegenereerde kolommen. Zo is een negatieve Kelvin-waarde een constraint-schending bij invoeging, en geen stille data-bug drie queries verderop.

CREATE OR REPLACE FUNCTION c_to_f(c numeric) RETURNS numeric AS $$
    SELECT c * 9.0 / 5.0 + 32.0;
$$ LANGUAGE SQL IMMUTABLE;

CREATE OR REPLACE FUNCTION c_to_k(c numeric) RETURNS numeric AS $$
    SELECT c + 273.15;
$$ LANGUAGE SQL IMMUTABLE;

CREATE TABLE sensor_readings (
    id          bigserial PRIMARY KEY,
    recorded_at timestamptz NOT NULL DEFAULT now(),
    celsius     numeric(6, 2) NOT NULL,
    fahrenheit  numeric(6, 2) GENERATED ALWAYS AS (c_to_f(celsius)) STORED,
    kelvin      numeric(6, 2) GENERATED ALWAYS AS (c_to_k(celsius)) STORED,
    CONSTRAINT  kelvin_non_negative CHECK (celsius >= -273.15)
);

INSERT INTO sensor_readings (celsius) VALUES (22.5), (0), (100);
SELECT celsius, fahrenheit, kelvin FROM sensor_readings;
-- 22.50 | 72.50  | 295.65
--  0.00 | 32.00  | 273.15
-- 100.00| 212.00 | 373.15

-- Rejected at insert time:
-- INSERT INTO sensor_readings (celsius) VALUES (-300);
-- ERROR: new row for relation "sensor_readings" violates check constraint

GENERATED ALWAYS AS ... STORED ruilt wat schijfruimte voor leessnelheid — je leest de waarde, je herberekent hem niet. Wissel STORED voor een view als schijfdruk belangrijker is dan leeslatentie bij IoT-tabellen met hoog volume.

Omgaan met weer- en IoT-API’s

De meest voorkomende productiebug met temperatuur is geen formulefout. Het is een eenheidsmismatch tussen wat een API teruggeeft en wat je UI weergeeft. De providers waar de meeste ontwikkelaars mee te maken hebben:

OpenWeatherMap geeft standaard Kelvin terug. Geef units=metric voor Celsius of units=imperial voor Fahrenheit door. Als je de queryparameter vergeet, krijg je Kelvin. Getallen zoals 284.15 die aankomen in een veld met de naam temp hebben genoeg ontwikkelaars misleid dat een integratietest de moeite waard is.

Open-Meteo geeft standaard Celsius terug en accepteert temperature_unit=fahrenheit. Geen Kelvin-optie — het is geen wetenschappelijke API.

Tomorrow.io en WeatherAPI gebruiken standaard metrisch maar geven beide schalen terug in hetzelfde antwoord onder verschillende sleutels. Lees de werkelijke sleutel waarnaar je code verwijst, niet de buur.

Het patroon dat ik gebruik voor elke weer- of sensor-ingestie:

type Reading = {
  value: number;
  scale: 'C' | 'F' | 'K';
  source: string;
};

function normalise(raw: Reading): number /* celsius */ {
  switch (raw.scale) {
    case 'C': return raw.value;
    case 'F': return (raw.value - 32) * 5 / 9;
    case 'K': return raw.value - 273.15;
  }
}

// At ingestion, every reading carries its scale explicitly.
// The UI layer never guesses — it consumes celsius and formats per user preference.

Twee regels volgen hieruit:

Elke ingestie-grens registreert de bronschaal. Geen kale getallen die modulesgrenzen oversteken.
De weergavelaag is de enige plek die omzet naar de voorkeurseenheid van de gebruiker.

Dubbele omrekening — waarbij twee lagen elk het getal “normaliseren” — is de andere veelvoorkomende bug. Een backend-team zet Kelvin om naar Celsius bij het schrijven. Een frontend-team, dat dit niet weet, past dezelfde - 273.15 toe bij het lezen. Gebruikers zien temperaturen rond −251°C. De oplossing is één eigenaar voor normalisatie, niet meer tests.

Bij IoT komen ruwe sensorgegevens vaak aan als een ADC-telling die via een kalibratiecurve naar temperatuur moet worden omgezet (voor een 10kΩ NTC-thermistor betekent dat de Steinhart-Hart-vergelijking). Temperatuurschaal-omrekeningen vinden daarna plaats, op de al gekalibreerde waarde. De twee fasen door elkaar halen is hoe je getallen krijgt die er temperatuurachtig uitzien maar 30% ernaast zitten.

Veelgemaakte fouten en hoe je ze vermijdt

Deze zes komen voor in echte productiecodebases. Controleer de jouwe hieraan.

De verkeerde formulerichting gebruiken

Veelvoorkomend symptoom: een app die 37°C kinderkoortstemperatuur weergeeft en het dan als kritiek markeert. Wat er is gebeurd: de API gaf 37°F terug, iemand bestempelde het als celsius omdat de kolomnaam dat zei, en de medische drempellogica vergeleek met een Celsius-schaal. Voorkom dit door het type de eenheid te laten dragen, niet de variabelenaam.

Temperatuur behandelen als extensief

averageTemperatuur slaat ergens op. sumTemperaturen niet. Als je aggregatie-SQL SUM(temperature_c) bevat, gaat er iets fout — je wilt waarschijnlijk AVG of, in zeldzame gevallen, een geïntegreerde graaddagmeting. Temperatuur is een intensieve grootheid; tel er niet twee van op en verwacht een zinvol resultaat.

Zwevendekomma-afronding

(37 * 9 / 5) + 32 geeft in JavaScript 98.60000000000001, niet 98.6. Elke taal die IEEE 754-doubles gebruikt, heeft hetzelfde gedrag. Opties:

Geef weer met .toFixed(2) (of het equivalent van je taal) en stop daar.
Gebruik een decimale bibliotheek (decimal.js, Python Decimal, BigDecimal) voor auditnauwkeurigheid.
Sla op als gehele getallen in deci-graden (370 in plaats van 37.0) en deel alleen bij weergave.

Voor weergave in een UI is toFixed(2) de juiste keuze. Voor een facturerings- of regelgevingssysteem waarbij afrondingsfouten zich opstapelen, gebruik je decimalen.

Negatieve Kelvin bij invoervalidatie

Kelvin is niet-negatief op grond van de fysische wet. Een request body met { "tempK": -10 } is altijd ongeldig. Dwing dit af aan de grens — JSON schema, Pydantic, Zod, CHECK-beperking — niet diep in de bedrijfslogica. De enige uitzondering, kwantumsystemen met “negatieve absolute temperatuur”, doet zich niet voor in een API die je waarschijnlijk integreert; als dat wel het geval is, weet je dat al.

Ontbrekende eenheidslabels in UI en logs

Een logregel die sensor 42: 37 zegt, is zes maanden later nutteloos. Is dat Celsius? Fahrenheit? Een ruwe ADC-telling? Schrijf altijd sensor 42: 37°C of structureer de log als { "sensor": 42, "value": 37, "unit": "celsius" }. Schijfruimte is goedkoop; productiebeheer om drie uur ‘s nachts niet.

Tijdzonesverwisseling met temperatuur

Reis-apps leveren deze bug: wanneer een gebruiker een tijdzone overschrijdt, verschuift de code behulpzaam elk veld met een tijdstempel — inclusief temperatuurmetingen. Temperatuur maakt niet uit voor tijdzones. Het tijdstempel op een meting heeft tijdzonelogica nodig; de meetwaarde zelf niet. Bewaar ze in aparte velden en stuur ze door aparte conversiepipelines.

Rekentrucjes uit je hoofd

Voor als je geen omrekentool bij de hand hebt.

Celsius naar Fahrenheit (ruw): verdubbel het, tel er 30 bij op. 20°C → 70°F (werkelijk 68). 30°C → 90°F (werkelijk 86). Nauwkeurig tot binnen 2–3°F over het bereik 0–40°C, wat elke temperatuur dekt die je buiten een oven ervaart.

Fahrenheit naar Celsius (ruw): trek er 30 af, halveer het. 80°F → 25°C (werkelijk 26,7). 60°F → 15°C (werkelijk 15,6). Dezelfde nauwkeurigheidsband.

Celsius naar Kelvin: tel er 273 bij op en rond af. Je verliest 0,15 K, wat onder de thermometernauwkeurigheid ligt voor alles buiten een fysicalaboratorium.

Twee ankerpunten die het waard zijn om te onthouden: 20°C = 68°F ≈ 293 K, en 100°C = 212°F = 373,15 K. Vanuit die twee punten brengt lineaire interpolatie je dicht genoeg voor elke schatting.

De vuistregels dekken reizen, kookinschattingen en weersvoorspellingen. Voor alles wat in code of een regulatoire aangifte terechtkomt, gebruik je de exacte formules — of open onze gratis temperatuur-omrekentool en kopieer de precieze waarde.

Referentietabellen

Alledaagse temperaturen

Context	Celsius	Fahrenheit	Kelvin
Thuisvriezer	−18°C	0°F	255,15 K
Vriespunt	0°C	32°F	273,15 K
Koelkast	4°C	39°F	277,15 K
Kamertemperatuur	20°C	68°F	293,15 K
Lichaamstemperatuur	37°C	98,6°F	310,15 K
Koortsdrempel	38°C	100,4°F	311,15 K
Hete zomerdag	35°C	95°F	308,15 K
Water kookt	100°C	212°F	373,15 K

Kook- en oveninstellingen

Oveninstelling	Celsius	Fahrenheit
Laag / langzaam garen	125°C	257°F
Warm bakken	150°C	302°F
Matig bakken	175°C	347°F
Standaard bakken (cakes)	180°C	356°F
Braden	190°C	374°F
Heet braden	200°C	392°F
Intensief braden	220°C	428°F
Pizza / broodkorst	250°C	482°F

Amerikaanse recepten ronden 350°F af naar 175°C of 180°C, afhankelijk van het kookboek; de exacte waarde is 176,67°C. Beide keuzes werken — huishoudelijke ovens houden de temperatuur sowieso zelden beter vast dan ±5°C.

Wetenschappelijke extremen

Fenomeen	Kelvin	Celsius
Absoluut nulpunt (theoretische grens)	0 K	−273,15°C
Kosmische microgolfachtergrond	2,725 K	−270,425°C
Vloeibaar helium (kookpunt, 1 atm)	4,2 K	−268,95°C
Supergeleider-overgang (YBCO)	93 K	−180,15°C
Vloeibare stikstof (kookpunt)	77 K	−196,15°C
Schaduw in de ruimte	~40 K	~−233°C
Droog ijs (sublimatie)	194,65 K	−78,5°C
Oppervlak van de zon	5.778 K	5.504,85°C
Kern van de zon	1,57×10⁷ K	1,57×10⁷ °C*
Tokamak-plasma (ITER-doel)	1,5×10⁸ K	~1,5×10⁸ °C*

*Bij deze grootteordes is de verschuiving van 273,15 K een afrondingsfout — Celsius en Kelvin lezen feitelijk identiek.

Veelgestelde vragen

Wat is de formule om Celsius naar Fahrenheit om te rekenen?

Vermenigvuldig Celsius met 9/5 (of 1,8) en tel er 32 bij op: °F = °C × 9/5 + 32. Bijvoorbeeld: 25°C × 1,8 + 32 = 77°F. De vermenigvuldiger weerspiegelt de verhouding 180:100 tussen de bereiken van de twee schalen van vriespunt tot kookpunt, en de 32 lijnt hun verschillende nulpunten op elkaar.

Wat is de formule om Fahrenheit naar Celsius om te rekenen?

Trek 32 af van de Fahrenheit-waarde en vermenigvuldig vervolgens met 5/9: °C = (°F − 32) × 5/9. Voor 72°F is de berekening (72 − 32) × 5/9 = 40 × 5/9 ≈ 22,22°C. Trek eerst af, vermenigvuldig daarna — de volgorde omdraaien geeft het verkeerde antwoord.

Bij welke temperatuur zijn Celsius en Fahrenheit gelijk?

Bij precies −40 graden. °C = °F invullen in de omrekenformule geeft °C = °C × 9/5 + 32, wat oplost tot °C = −40. Dit is de enige temperatuur waarbij de twee schalen hetzelfde getal tonen, en het is een handig ijkpunt voor zowel echte koude perioden als fouten in de omrekenrichting.

Hoe reken ik 350°F naar Celsius om voor bakken?

350°F is gelijk aan ongeveer 176,67°C. Europese recepten ronden dit doorgaans af naar 180°C, en veel Amerikaanse-naar-metrische omrekenlijsten gebruiken 175°C. Beide werken in een huishoudelijke oven — de temperatuurstabiliteit in dat bereik is slechter dan de afrondingsfout. Gebruik onze temperatuur-omrekentool voor exacte waarden als nauwkeurigheid telt.

Wat is 100°F in Celsius?

100°F ≈ 37,78°C. Dit ligt net boven de normale lichaamstemperatuur (37°C / 98,6°F) en wordt vaak aangemerkt als het begin van lichte koorts. Medische richtlijnen gebruiken 38°C / 100,4°F als de echte koortsdrempel, dus 100°F is grensgevaarlijk maar nog niet klinisch significant.

Waarom is het absolute nulpunt −273,15°C en niet gewoon −273?

Omdat de SI-herdefinitie van 2019 de Boltzmann-constante exact vastlegde, waardoor −273,15°C de precieze berekende waarde van het absolute nulpunt is in plaats van een afgeronde benadering. Voor 2019 was het Celsius-nulpunt gekoppeld aan het tripelpunt van water en kwam de 0,15 uit meting. Nu is het exact per definitie.

Wanneer gebruik ik Kelvin in plaats van Celsius in code?

Elke keer dat je een temperatuur vermenigvuldigt, deelt of tot een macht verheft — zwartlichaamstraling (T⁴), ideale gasberekeningen, reactiesnelheden. Kelvin wordt nooit negatief, dus deling blijft stabiel. Voor temperatuurverschillen zijn Celsius en Kelvin uitwisselbaar (een verandering van 5 graden is hetzelfde in beide).

Wordt Rankine nog gebruikt in 2026?

Ja, maar beperkt. De Amerikaanse werktuigbouwkunde, HVAC en ruimtevaarttechniek gebruiken Rankine nog steeds voor analyse van thermodynamische cycli waarbij alle andere invoer in Fahrenheit is. Buiten die vakgebieden en buiten de Verenigde Staten is het feitelijk dood. Als je algemene software schrijft, is Rankine ondersteunen een goedkope verzekering, maar zelden essentieel.

Hoe reken ik temperatuur om in een SQL-query?

Gebruik de formule inline of gebruik een GENERATED ALWAYS AS-kolom. Voorbeeld: SELECT celsius * 9.0 / 5.0 + 32.0 AS fahrenheit FROM readings. De 9.0 en 5.0 (niet 9 en 5) dwingen zwevende-komma-rekenkunde af in de meeste dialecten; integer-deling wordt stilzwijgend afgekapt. Voeg een CHECK (celsius >= -273.15) toe om onzinnige waarden bij invoeging te weigeren.

Wat is de makkelijkste manier om Celsius naar Fahrenheit in je hoofd om te rekenen?

Verdubbel de Celsius-waarde en tel er 30 bij op. 22°C × 2 + 30 = 74°F (werkelijk 71,6°F). Nauwkeurig tot binnen ongeveer 2°F voor het bereik 0–30°C, wat bijna alle weer- en binnentemperaturen dekt. Omgekeerd: trek 30 af van Fahrenheit en halveer het.

Waarom geeft mijn temperatuuromrekentool 98,599999 voor 37°C?

Omdat 9/5 = 1,8 niet exact kan worden weergegeven in binaire zwevendekomma, komt 37 × 9 / 5 + 32 uit op 98.60000000000001 in plaats van 98.6. Dit is IEEE 754-gedrag, geen bug. Gebruik toFixed(2) voor weergave, of schakel over op een decimale bibliotheek als precisie op het laatste cijfer in je domein telt.

Kan ik temperaturen als gehele getallen opslaan om zwevendekomma-problemen te vermijden?

Ja — sla deci-Celsius op (de temperatuur maal 10). 37,0°C wordt 370, 22,5°C wordt 225. Gehele-getalrekenkunde is exact, en je deelt door 10 alleen aan de weergavegrens. Dit patroon is gebruikelijk in embedded systemen en tijdreeksdatabases met hoog volume waar schijf en CPU tellen.

Hoe ga ik om met eenheidloze getallen in een API-antwoord?

Dat doe je niet. Elk temperatuurveld moet een expliciete eenheid dragen, hetzij in de veldnaam (temp_celsius, temp_k) of in een aangrenzend unit-veld. Als je de consument bent en de API dit niet biedt, documenteer de aanname dan duidelijk in de code en schrijf een contracttest die breekt als de standaard van de API verandert.

Wat is het kookpunt van water op alle vier de schalen?

100°C = 212°F = 373,15 K = 671,67°R, bij standaard atmosferische druk (één atmosfeer, 101.325 kPa). Druk is bepalend voor het kookpunt: op de hoogte van Denver kookt water rond 95°C; op de top van de Everest dichter bij 71°C. Het kookpunt is een drukafhankelijke grootheid, geen universele constante.

Gedraagt temperatuur zich anders bij zwevendekomma-berekeningen dan andere getallen?

Nee — temperatuurwaarden gedragen zich als elk ander zwevendekommagetal. Het praktische probleem is dat de factoren 5/9 en 9/5 in de omrekenformules bij elke omrekenstap afrondingsfout introduceren. Voor Kelvin-waarden in het bereik 200–400 is de precisie ruim voldoende. Voor sub-nul Celsius-waarden dicht bij de grens van representeerbare doubles blijft de precisie ook goed. De echte valkuil is dat aaneengeschakelde omrekeningen kleine fouten opstapelen — zet één keer om en sla de canonieke vorm op.