Temperaturumrechnung: Celsius, Fahrenheit, Kelvin

Am Montag gehen Sie mit einem Wetter-Dashboard live. Am Mittwoch meldet eine Nutzerin aus Toronto einen Fehler: Die App zeigt die Außentemperatur als 284 an. Der OpenWeatherMap-Endpunkt hat Kelvin geliefert (so der Default), Ihre UI hat Celsius erwartet, und dazwischen hat schlicht niemand nachgerechnet. Eine fehlende Subtraktion, ein peinlicher Screenshot auf Twitter.

Wenn Sie nur die beiden Formeln brauchen und weiterziehen möchten:

Formel Celsius zu Fahrenheit: °F = °C × 9/5 + 32
Formel Fahrenheit zu Celsius: °C = (°F − 32) × 5/9
Celsius zu Kelvin: K = °C + 273,15

Die drei Formeln decken rund 90 % dessen ab, was Entwickler wirklich brauchen. Der Rest dieses Leitfadens sind die anderen 10 %: woher 9/5 kommt, warum Kelvin nie negativ wird, wie Sie Ihr Typsystem dazu bringen, celsiusToFahrenheit(kelvinValue) schon zur Compile-Zeit abzuweisen, und wie Sie den Toronto-Bug zuverlässig loswerden. Sie können das Lesen auch ganz überspringen und einfach unseren Temperaturumrechner nehmen, wenn Sie jetzt sofort einen Zahlenwert brauchen. Für andere Einheiten siehe den Komplett-Leitfaden zur Einheitenumrechnung.

Warum Temperatur anders ist als andere Einheitenumrechnungen

Die meisten Einheitenumrechnungen laufen trivial linear durch den Nullpunkt. Ein Meter sind 3,28084 Fuß, Punkt. Doppelt so viele Meter, doppelt so viele Fuß. Null Meter gleich null Fuß. Eine Umrechnungsbibliothek kommt mit einer einzigen multiplikativen Konstante pro Paar aus, und danach müssen Sie nie wieder darüber nachdenken.

Bei Temperatur bricht dieses Modell an einer entscheidenden Stelle: Die Skalen teilen keinen gemeinsamen Nullpunkt. Celsius verankert seine Null am Gefrierpunkt von Wasser. Fahrenheit verankert seine Null an einer Salzlake-Mischung aus dem Jahr 1724. Kelvin verankert seine Null am theoretischen Grund der Thermodynamik. Um zwischen zwei beliebigen Skalen zu wechseln, brauchen Sie einen Skalierungsfaktor und einen Offset — Temperatur ist eine affine Transformation, keine lineare.

Das hat eine konkrete, gefährliche Folge: Temperaturwerte sind nicht additiv wie Längen oder Massen. 20°C + 20°C ergibt in keinem physikalischen Sinn 40°C. Sie können nicht „zwei Räume zusammenzählen” und einen wärmeren Raum daraus bekommen. Eine Temperaturdifferenz dürfen Sie aber sehr wohl zu einer Temperatur addieren, denn Differenzen sind linear. Genau diese Unterscheidung ist beim Medeva-Impfstoff-Vorfall 2006 in Großbritannien ins Rutschen geraten: Ein pharmazeutischer Kühlkettenlogger verwechselte eine absolute Messung mit einer Differenz und markierte Tausende Dosen als außerhalb der Spezifikation. Intensive Größen wie Temperatur brauchen immer dieses gedankliche Geländer: Zahlen, die sich eine Einheit teilen, teilen sich nicht automatisch auch die Algebra.

Die vier Temperaturskalen erklärt

Für alltäglichen Code zählen nur zwei Skalen (Celsius, Fahrenheit), für alles Wissenschaftliche kommt Kelvin dazu, und die vierte taucht genau an einer Stelle auf: in US-amerikanischen Thermodynamik-Lehrbüchern und in den HVAC-Codebases, die sie noch zitieren.

Celsius (°C)

Anders Celsius veröffentlichte seine Skala 1742, ursprünglich mit 0° beim Sieden und 100° beim Gefrieren — also genau andersherum als heute. Die moderne Ausrichtung mit 0°C am Gefrierpunkt von Wasser und 100°C am Siedepunkt bei Standardatmosphäre kam kurz nach seinem Tod. Heute ist sie die vom SI abgeleitete Einheit für die Alltagstemperatur und die Standardskala in allen Ländern außer den Vereinigten Staaten, den Bahamas, Belize, den Kaimaninseln und Liberia.

Die SI-Neudefinition von 2019 hat Celsius sauber an Kelvin gebunden: 0°C ist nun als exakt 273,15 K definiert. Der Gefrierpunkt von Wasser, einst die Definition, ist jetzt eine gemessene Folge davon (er trifft auf wenige Millionstel genau 0°C, ist aber nicht mehr der Anker).

Fahrenheit (°F)

Daniel Gabriel Fahrenheit stellte seine Skala 1724 vor. Er wählte 0°F als Gefrierpunkt einer bestimmten Salzlake-Mischung — die kälteste Temperatur, die er in einem Danziger Winter zuverlässig reproduzieren konnte — und 96°F als Körpertemperatur. Eine spätere Neukalibrierung am Gefrier- und Siedepunkt von reinem Wasser verschob die Körpertemperatur auf 98,6°F und legte Gefrieren bei 32°F und Sieden bei 212°F fest — eine Spanne von 180 Grad.

Fahrenheit hält sich in den Vereinigten Staaten für Wetter, Kochen und medizinische Anwendungen. Die 180-Grad-Spanne zwischen Gefrieren und Sieden (statt 100 bei Celsius) wird manchmal damit verteidigt, sie biete „feinere Auflösung für Umgebungstemperaturen” — ein eher dünnes Argument, das aber erklärt, warum amerikanische Thermostate in 1°F-Schritten markiert sind, während europäische meist 0,5°C-Schritte nutzen.

Kelvin (K)

William Thomson, Lord Kelvin, schlug 1848 eine absolute Skala vor. Das moderne Kelvin ist die SI-Basiseinheit der Temperatur. Seit der SI-Neudefinition 2019 ist das Kelvin exakt an die Boltzmann-Konstante k_B = 1,380649 × 10⁻²³ J/K gebunden — damit ist es eine definierte und keine gemessene Größe mehr.

Drei Eigenheiten von Kelvin sollten Entwickler kennen:

Kein Gradzeichen. Schreiben Sie 300 K, nicht 300°K. So will es die SI-Konvention seit 1967.
Beginnt beim absoluten Nullpunkt. 0 K = −273,15°C. In validen Daten dürfen Sie nie einen negativen Kelvin-Wert sehen; behandeln Sie ihn als Eingabefehler.
Gleiche Gradgröße wie Celsius. Eine Änderung um 1 K entspricht einer Änderung um 1°C. Temperaturdifferenzen sind zwischen beiden austauschbar; nur bei den Absolutwerten liegt der Offset von 273,15 dazwischen.

Kelvin ist die richtige Wahl, wenn Sie Temperaturen multiplizieren oder dividieren — thermische Strahlung (T⁴), ideales Gasgesetz, Schwarzkörper-Physik. Eine Division durch einen negativen oder fast-null Celsius-Wert sprengt Ihnen Physik, die Sie fast immer endlich halten möchten.

Rankine (°R)

William Rankine schlug diese Skala 1859 als Fahrenheit-Pendant zu Kelvin vor: eine absolute Skala, Null beim absoluten Nullpunkt, aber mit Graden in Fahrenheit-Größe. 0°R = −459,67°F. 491,67°R = 0°C.

Außerhalb der US-amerikanischen Thermodynamik-Technik begegnet Ihnen Rankine kaum — HVAC-Berechnungen, Erdölraffinerie, Raketentriebwerk-Verbrennungsanalyse — überall dort, wo die Rechnung eine absolute Skala verlangt, die Eingangsdaten aber in Fahrenheit vorliegen. Die Umrechnung ist mechanisch: °R = °F + 459,67, oder gleichwertig °R = K × 9/5. Moderne Engineering-Software kann intern in Kelvin rechnen und nur für die Anzeige konvertieren — das empfehle ich, wann immer Sie die Wahl haben.

Formeln zur Temperaturumrechnung (alle sechs Richtungen)

Sechs Richtungen, vier Skalen, sechs Formeln. In der Praxis merkt man sich die Celsius-zentrierten und setzt den Rest daraus zusammen.

Celsius zu Fahrenheit und zurück

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

Der Faktor 9/5 ist das Verhältnis der Spannen beider Skalen zwischen denselben zwei physikalischen Landmarken. Vom Gefrier- zum Siedepunkt deckt Fahrenheit 180 Grad ab (32 bis 212); Celsius deckt 100 ab (0 bis 100). 180 / 100 = 9/5 = 1,8. Das + 32 ist der Offset, der die Nullpunkte am Gefrierpunkt angleicht, denn der Nullpunkt von Fahrenheit liegt 32°F unter dem von Celsius.

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

Celsius zu Kelvin und zurück

K = °C + 273,15
°C = K − 273,15

Keine Skalierung, nur ein Offset. 273,15 ist der numerische Abstand vom Celsius-Nullpunkt (Gefrierpunkt von Wasser) hinunter zum absoluten Nullpunkt, gemessen in Celsius-Graden. Weil Kelvin und Celsius dieselbe Gradgröße teilen, gibt es keinen Multiplikator.

Fahrenheit zu Kelvin und zurück

K = (°F − 32) × 5/9 + 273,15
°F = (K − 273,15) × 9/5 + 32

Eine kürzere Form gibt es nicht — nötig sind ein Skalenwechsel und ein Offset-Wechsel. Im Code ist es fast immer sauberer, über Celsius zu gehen: k = cToK(fToC(f)). Sie schreiben weniger, vertrauen dem Ergebnis mehr, und der Compiler optimiert die Komposition ohnehin weg.

Rankine-Umrechnungen

°R = °F + 459,67
°F = °R − 459,67
°R = K × 9/5
K  = °R × 5/9
°R = °C × 9/5 + 491,67

491,67 ist 32 × 9/5 + 459,67, also der Rankine-Wert, der 0°C entspricht. In der Praxis werden Sie diese Formeln kaum zusammensetzen. Wenn Sie Rankine doch brauchen, denken Sie an es als „absolutes Zwillings-Fahrenheit” und gehen über Fahrenheit oder Kelvin.

Woher kommt 9/5? Eine kurze Herleitung

Die beiden Skalen hängen über eine affine Funktion °F = a × °C + b zusammen. Um a und b zu bestimmen, brauchen Sie zwei bekannte Kalibrierungspunkte. Gefrier- und Siedepunkt sind das übliche Paar:

Gefrieren: 0°C ↔ 32°F
Sieden: 100°C ↔ 212°F

Beide in °F = a × °C + b einsetzen:

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

Das war’s — zwei lineare Gleichungen, zwei Unbekannte, und die komplette Umrechnung fällt heraus. Geometrisch: Stellen Sie sich zwei senkrechte Thermometer nebeneinander vor, eines in Celsius, eines in Fahrenheit. Das Fahrenheit-Thermometer ist vertikal gedehnt (Steigung 9/5) und nach oben verschoben (Achsenabschnitt 32) relativ zum Celsius-Thermometer. Jeder andere Umrechnungswert liegt auf genau dieser gedehnten und verschobenen Geraden.

Dieselbe Herleitung mit (0°C, 273,15 K) und (100°C, 373,15 K) liefert Celsius-zu-Kelvin: Steigung 1, Achsenabschnitt 273,15. Mit zwei beliebigen eindeutigen Kalibrierungspunkten kommen Sie zu jeder affinen Umrechnung. Mathematisch ist an Temperatur nichts Besonderes — die Komplexität sitzt ausschließlich in der Zwei-Anker-Konfiguration, die andere Einheitentypen nicht brauchen.

Der −40°-Schnittpunkt: Eine nützliche Eselsbrücke

Gibt es eine Temperatur, bei der Celsius und Fahrenheit denselben Zahlenwert zeigen? Setzen Sie °C = °F in die Umrechnungsformel ein:

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

Also −40°C = −40°F. Genau ein Kreuzungspunkt — und es ist eine reale Temperatur, die Sie im Januar in Yellowknife, Jakutsk oder Fairbanks treffen können. Nebenbei ein günstiger Mental-Check: Wenn Sie eine C↔F-Umrechnung im Kopf überschlagen und das Ergebnis in der Nähe von −40 liegt, sollten beide Zahlen dicht beieinanderliegen. Steht auf der einen Seite −40°C und auf der anderen −72°F, haben Sie die Richtung verdreht.

Ich habe die komplette Eselsbrücken-Liste neben meinem Monitor kleben: Gefrieren (0 / 32), Körpertemperatur (37 / 98,6), Raumtemperatur (20 / 68), Sieden (100 / 212), −40 (−40 / −40). Fünf Punkte decken fast jeden Plausibilitäts-Check ab, den ich brauche.

Temperaturumrechnung im Code

Die Formeln sind trivial. Sie in einer realen Codebasis sauber hinzubekommen, hängt vor allem an zwei Dingen: verhindern, dass ein Aufrufer Fahrenheit übergibt, wo Sie Celsius erwartet haben, und das Fließkommaverhalten an den Grenzen (Gefrierpunkt, absoluter Nullpunkt, Backofentemperaturen) berechenbar halten. Jedes Beispiel unten ist ein vollständiges, ausführbares Programm.

JavaScript / TypeScript

Reines JavaScript liefert sofort funktionierende Umrechnungen:

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

Mit TypeScript lassen sich Einheiten-Verwechslungen zu Compile-Fehlern umdeklarieren, indem Sie den Zahlentyp brandieren:

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-Fehler: Temp<'F'> ist nicht Temp<'C'>

Branded Types haben keine Laufzeitkosten und kosten Sie etwa zehn Zeilen Boilerplate. Dafür wird aus dem Toronto-Bug aus dem Einleitungsabsatz eine rote Schlangenlinie in Ihrem Editor.

Python

Einfache Funktionen reichen oft, aber ein Enum plus dataclass zahlt sich schon beim ersten Logging einer Temperatur aus:

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"Unbekannte Skala: {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"Unbekannte Skala: {scale}")

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

Wenn Sie wissenschaftliche Daten verarbeiten, bei denen 0.1 + 0.2 != 0.3 zum Audit-Problem wird, ersetzen Sie float durch decimal.Decimal. Der Tradeoff: Geschwindigkeit (Decimal ist rund 50-mal langsamer) und die Tatsache, dass auch 5/9 keine exakte dezimale Darstellung hat — Sie brauchen also Decimal(5) / Decimal(9) mit kontrolliertem Kontext. Für die meisten Sensor-Pipelines reicht float plus round(value, 2) an der Anzeigegrenze vollkommen.

Go

Gos Typsystem geht noch weiter als TypeScript: Ein benannter float64-Typ lässt sich nicht stillschweigend mit einem anderen benannten float64-Typ mischen, selbst wenn beide dieselbe Laufzeit-Repräsentation haben.

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-Fehler
    // fmt.Println(room.ToKelvin() + 1)   // Compile-Fehler: Kelvin + untyped int braucht Kelvin(1)
}

Der Aufwand: rund eine Zeile pro Skala. Der Nutzen: ToFahrenheit kann keinen Kelvin-Wert versehentlich schlucken, und eine Funktion, die Celsius erwartet, weist ein rohes float64 schon an der Aufrufstelle zurück.

Rust

Rusts Newtype-Muster liefert dieselben Garantien wie Go, dazu günstige From/Into-Konvertierungen:

#[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)
}

Darauf lässt sich Validierung aufsetzen: Ein TryFrom<f64> for Kelvin, das negative Werte ablehnt, liefert Result<Kelvin, TemperatureError> und zieht die Prüfung in den Konstruktionszeitpunkt vor. Ungültige Zustände erreichen Ihre Geschäftslogik nie.

SQL (PostgreSQL)

Speichern Sie Temperaturen mit CHECK-Constraints und leiten Sie alternative Einheiten als generierte Spalten ab. Dann ist ein negativer Kelvin-Wert beim Insert eine Constraint-Verletzung, kein stiller Datenfehler drei Queries später.

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

-- Beim Insert abgewiesen:
-- INSERT INTO sensor_readings (celsius) VALUES (-300);
-- ERROR: new row for relation "sensor_readings" violates check constraint

GENERATED ALWAYS AS ... STORED tauscht etwas Speicher gegen Abfragegeschwindigkeit — Sie lesen den Wert, Sie berechnen ihn nicht neu. Bei IoT-Tabellen mit hohem Volumen ersetzen Sie STORED durch einen View, wenn Speicherdruck wichtiger ist als Lese-Latenz.

Umgang mit Wetter- und IoT-APIs

Der häufigste Produktionsfehler bei Temperatur ist kein Formelfehler. Es ist ein Einheiten-Mismatch zwischen dem, was eine API zurückgibt, und dem, was Ihre UI anzeigt. Eine kurze Tour durch die Anbieter, denen die meisten Entwickler begegnen:

OpenWeatherMap liefert standardmäßig Kelvin. Hängen Sie units=metric für Celsius an oder units=imperial für Fahrenheit. Der Knackpunkt: Vergessen Sie den Query-Parameter, bekommen Sie Kelvin. Zahlen wie 284.15, die in einem Feld namens temp ankommen, haben schon genug Ingenieure reingelegt, um einen Integrationstest zu rechtfertigen.

Open-Meteo liefert standardmäßig Celsius und akzeptiert temperature_unit=fahrenheit. Keine Kelvin-Option — es ist keine wissenschaftliche API.

Tomorrow.io und WeatherAPI sind standardmäßig metrisch, liefern aber beide Skalen in derselben Antwort unter verschiedenen Keys. Lesen Sie exakt den Key, den Ihr Code referenziert, nicht den Nachbar-Key.

Das Muster, das ich für jede Wetter- oder Sensor-Datenaufnahme nehme:

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;
  }
}

// Bei der Aufnahme trägt jede Messung ihre Skala explizit mit.
// Die UI-Schicht rät nie — sie konsumiert Celsius und formatiert nach Nutzer-Vorliebe.

Daraus folgen zwei Regeln:

Jede Aufnahmegrenze protokolliert die Quellskala. Keine nackten Zahlen, die Modul-Grenzen überschreiten.
Die Anzeigeschicht ist der einzige Ort, der in die Wunscheinheit des Nutzers konvertiert.

Doppelte Konvertierung — bei der zwei Schichten die Zahl jeweils „normalisieren” — ist der andere häufige Bug. Ein Backend-Team konvertiert Kelvin beim Schreiben zu Celsius. Ein Frontend-Team wendet beim Lesen nichts ahnend erneut - 273.15 an. Nutzer sehen Temperaturen um −251°C. Die Lösung ist ein einziger Verantwortlicher für die Normalisierung, nicht mehr Tests.

Im IoT-Bereich kommen Rohsensor-Daten oft als ADC-Count an, den Sie über eine Kalibrierkurve in Temperatur umrechnen müssen (bei einem 10 kΩ NTC-Thermistor heißt das Steinhart-Hart-Gleichung). Skalen-Umrechnungen passieren danach, auf dem bereits kalibrierten Wert. Mischen Sie die beiden Phasen, landen Sie bei Zahlen, die wie Temperaturen aussehen, aber um 30 % danebenliegen.

Häufige Fallstricke und wie Sie sie vermeiden

Diese sechs begegnen einem in echten Produktions-Codebases. Prüfen Sie Ihre dagegen.

Die falsche Formelrichtung verwenden

Häufigstes Symptom: Eine App zeigt 37°C Säuglingsfieber an und markiert es dann als kritisch. Tatsächlich hatte die API 37°F geliefert, jemand nannte das Feld celsius, weil der Spaltenname das sagte, und die medizinische Schwellenlogik verglich gegen die Celsius-Skala. Verhindern Sie das, indem Sie den Typ die Einheit tragen lassen, nicht den Variablennamen.

Temperatur als extensive Größe behandeln

averageTemperature ist sinnvoll. sumTemperatures nicht. Wenn Ihre Aggregations-SQL SUM(temperature_c) enthält, stimmt etwas nicht — Sie möchten wahrscheinlich AVG oder, in seltenen Fällen, eine integrierte Gradtag-Metrik. Temperatur ist eine intensive Größe; addieren Sie nie zwei Temperaturen und erwarten ein sinnvolles Ergebnis.

Fließkomma-Rundung

(37 * 9 / 5) + 32 ergibt in JavaScript 98.60000000000001, nicht 98.6. Jede Sprache mit IEEE-754-Doubles zeigt dasselbe Verhalten. Optionen:

Mit .toFixed(2) (oder dem Äquivalent Ihrer Sprache) anzeigen und dabei bleiben.
Eine Decimal-Bibliothek nehmen (decimal.js, Python Decimal, BigDecimal) für audit-taugliche Genauigkeit.
Als Ganzzahlen in Dezi-Grad speichern (370 statt 37.0) und nur bei der Anzeige dividieren.

Für die Anzeige in einer UI ist toFixed(2) fast immer richtig. Für Abrechnungs- oder Regulierungssysteme, in denen sich Rundungsfehler aufaddieren, nehmen Sie Decimals.

Negatives Kelvin bei der Eingabevalidierung

Kelvin ist laut physikalischem Gesetz nicht-negativ. Ein Request-Body mit { "tempK": -10 } ist immer ungültig. Setzen Sie das an der Grenze durch — JSON Schema, Pydantic, Zod, CHECK-Constraint — nicht erst tief in der Geschäftslogik. Die einzige Ausnahme, Quantensysteme mit „negativer absoluter Temperatur”, trifft keine API, die Sie realistisch integrieren werden; falls doch, wissen Sie das ohnehin.

Fehlende Einheiten-Labels in UI und Logs

Eine Log-Zeile sensor 42: 37 ist sechs Monate später nutzlos. Ist das Celsius? Fahrenheit? Ein roher ADC-Count? Schreiben Sie immer sensor 42: 37°C oder strukturieren Sie das Log als { "sensor": 42, "value": 37, "unit": "celsius" }. Speicherplatz ist billig; Produktions-Triage um drei Uhr nachts ist es nicht.

Zeitzonen-Verwirrung vs. Temperatur

Reise-Apps bringen diesen Bug gelegentlich mit: Wenn ein Nutzer eine Zeitzone überquert, verschiebt der Code hilfsbereit jedes zeitgestempelte Feld — inklusive der Temperaturmessungen. Temperatur schert sich nicht um Zeitzonen. Der Zeitstempel einer Messung braucht Zeitzonenlogik; der Messwert nicht. Halten Sie sie in getrennten Feldern und führen Sie sie durch getrennte Konvertierungs-Pipelines.

Kopfrechen-Abkürzungen

Für den Fall, dass Sie keinen Konverter offen haben.

Celsius zu Fahrenheit (grob): verdoppeln, 30 dazu. 20°C → 70°F (tatsächlich 68). 30°C → 90°F (tatsächlich 86). Auf 2–3°F genau über den Bereich 0–40°C, und der deckt fast jede Temperatur ab, die Sie außerhalb eines Brennofens erleben.

Fahrenheit zu Celsius (grob): 30 abziehen, halbieren. 80°F → 25°C (tatsächlich 26,7). 60°F → 15°C (tatsächlich 15,6). Gleiches Genauigkeitsband.

Celsius zu Kelvin: 273 addieren und runden. Sie verlieren 0,15 K, und das liegt unter der Thermometerpräzision für alles außerhalb eines Physiklabors.

Zwei merkwürdige Anker: 20°C = 68°F ≈ 293 K und 100°C = 212°F = 373,15 K. Aus diesen beiden kommen Sie per linearer Interpolation nah genug für jede Schätzung.

Die Daumenregeln decken Reise, grobes Kochen und Wetterprognosen ab. Für alles, was in Code oder eine behördliche Meldung einfließt, nutzen Sie die exakten Formeln — oder öffnen Sie unser kostenloses Tool zur Temperaturumrechnung und kopieren den exakten Wert.

Referenztabellen

Alltagstemperaturen

Kontext	Celsius	Fahrenheit	Kelvin
Haushaltsgefrierer	−18°C	0°F	255,15 K
Gefrierpunkt	0°C	32°F	273,15 K
Kühlschrank	4°C	39°F	277,15 K
Raumtemperatur	20°C	68°F	293,15 K
Körpertemperatur	37°C	98,6°F	310,15 K
Fieberschwelle	38°C	100,4°F	311,15 K
Heißer Sommertag	35°C	95°F	308,15 K
Wasser siedet	100°C	212°F	373,15 K

Koch- und Backofen-Umrechnungen

Backofenstufe	Celsius	Fahrenheit
Niedrig / Schonend garen	125°C	257°F
Warm backen	150°C	302°F
Moderates Backen	175°C	347°F
Standard-Backen (Kuchen)	180°C	356°F
Braten	190°C	374°F
Heißes Braten	200°C	392°F
Hohes Braten	220°C	428°F
Pizza / Brotkruste	250°C	482°F

Amerikanische Rezepte runden 350°F je nach Kochbuch auf 175°C oder 180°C; der exakte Wert ist 176,67°C. Beides funktioniert — Haushaltsöfen halten die Temperatur ohnehin selten besser als ±5°C.

Wissenschaftliche Extremwerte

Phänomen	Kelvin	Celsius
Absoluter Nullpunkt (theor. Grenze)	0 K	−273,15°C
Kosmische Mikrowellenhintergrundstr.	2,725 K	−270,425°C
Flüssiges Helium (siedend, 1 atm)	4,2 K	−268,95°C
Supraleiter-Übergang (YBCO)	93 K	−180,15°C
Flüssiger Stickstoff (siedend)	77 K	−196,15°C
Tiefer Weltraum, Schatten	~40 K	~−233°C
Trockeneis (Sublimation)	194,65 K	−78,5°C
Sonnenoberfläche	5.778 K	5.504,85°C
Sonnenkern	1,57×10⁷ K	1,57×10⁷ °C*
Tokamak-Plasma (ITER-Zielwert)	1,5×10⁸ K	~1,5×10⁸ °C*

*Bei diesen Größenordnungen ist der Offset von 273,15 K ein Rundungsfehler — Celsius und Kelvin liest man praktisch identisch.

FAQ

Wie lautet die Formel zur Umrechnung von Celsius in Fahrenheit?

Multiplizieren Sie Celsius mit 9/5 (oder 1,8) und addieren Sie anschließend 32: °F = °C × 9/5 + 32. Beispiel: 25°C × 1,8 + 32 = 77°F. Der Multiplikator spiegelt das Verhältnis 180:100 zwischen den Spannen beider Skalen vom Gefrier- zum Siedepunkt; die 32 gleicht die unterschiedlichen Nullpunkte aus.

Wie lautet die Formel zur Umrechnung von Fahrenheit in Celsius?

Ziehen Sie 32 vom Fahrenheit-Wert ab und multiplizieren Sie dann mit 5/9: °C = (°F − 32) × 5/9. Für 72°F ergibt sich (72 − 32) × 5/9 = 40 × 5/9 ≈ 22,22°C. Zuerst subtrahieren, dann multiplizieren — eine vertauschte Reihenfolge liefert das falsche Ergebnis.

Bei welcher Temperatur sind Celsius und Fahrenheit gleich?

Bei genau −40 Grad. Setzt man °C = °F in die Umrechnungsformel ein, ergibt sich °C = °C × 9/5 + 32 und damit °C = −40. Das ist die einzige Temperatur, bei der beide Skalen denselben Zahlenwert zeigen — eine nützliche Orientierungsmarke für reale Kälteeinbrüche und zugleich ein Marker für Richtungsfehler bei Umrechnungen.

Wie rechne ich 350°F zum Backen in Celsius um?

350°F entsprechen rund 176,67°C. Europäische Rezepte runden meist auf 180°C, viele Umrechnungstabellen von amerikanisch zu metrisch nehmen 175°C. Beides klappt im Haushaltsofen — die Temperaturstabilität in diesem Bereich ist schlechter als der Rundungsfehler. Nutzen Sie unser Tool zur Temperaturumrechnung für exakte Werte, wenn Präzision zählt.

Was sind 100°F in Celsius?

100°F ≈ 37,78°C. Das liegt knapp über der normalen Körpertemperatur (37°C / 98,6°F) und wird oft als Beginn eines leichten Fiebers markiert. Medizinische Leitlinien setzen üblicherweise 38°C / 100,4°F als echte Fieberschwelle an — 100°F ist also ein Grenzfall, aber noch nicht klinisch signifikant.

Warum ist der absolute Nullpunkt −273,15°C und nicht einfach −273?

Weil die SI-Neudefinition 2019 die Boltzmann-Konstante exakt festgelegt hat. Dadurch wird −273,15°C zum präzise berechneten Wert des absoluten Nullpunkts, nicht zu einer gerundeten Näherung. Vor 2019 hing der Celsius-Nullpunkt am Tripelpunkt des Wassers, und die 0,15 stammten aus der Messung. Jetzt sind sie per Definition exakt.

Wann sollte ich in Code Kelvin statt Celsius verwenden?

Immer dann, wenn Sie eine Temperatur multiplizieren, dividieren oder potenzieren — Schwarzkörperstrahlung (T⁴), Rechnungen mit idealem Gas, Reaktionsgeschwindigkeiten. Kelvin wird nie negativ, die Division bleibt also stabil. Für Temperaturdifferenzen sind Celsius und Kelvin austauschbar (eine Änderung von 5 Grad ist in beiden gleich).

Wird Rankine im Jahr 2026 noch verwendet?

Ja, aber nur in engen Nischen. Die US-amerikanische Maschinenbau-, HVAC- und Raumfahrttechnik nutzt Rankine weiterhin für Analysen thermodynamischer Kreisprozesse, bei denen alle anderen Eingaben in Fahrenheit vorliegen. Außerhalb dieser Felder und außerhalb der Vereinigten Staaten ist es praktisch ausgestorben. Wenn Sie Allzweck-Software schreiben, ist Rankine-Unterstützung eine günstige Absicherung, aber selten zentral.

Wie rechne ich Temperatur in einer SQL-Abfrage um?

Schreiben Sie die Formel inline oder nehmen Sie eine GENERATED ALWAYS AS-Spalte. Beispiel: SELECT celsius * 9.0 / 5.0 + 32.0 AS fahrenheit FROM readings. Die 9.0 und 5.0 (nicht 9 und 5) erzwingen in den meisten Dialekten Fließkomma-Arithmetik; andernfalls schneidet Ganzzahl-Division stillschweigend ab. Mit einem CHECK (celsius >= -273.15) weisen Sie Unsinnswerte schon beim Insert ab.

Wie rechne ich Celsius am einfachsten im Kopf in Fahrenheit um?

Verdoppeln Sie den Celsius-Wert und addieren Sie 30. 22°C × 2 + 30 = 74°F (tatsächlich 71,6°F). Auf rund 2°F genau über den Bereich 0–30°C, und der deckt fast alle Wetter- und Innenraum-Temperaturen ab. Umgekehrt: von Fahrenheit 30 abziehen und halbieren.

Warum liefert mein Temperaturumrechner 98,599999 für 37°C?

Weil 9/5 = 1,8 binär nicht exakt darstellbar ist, kommt 37 × 9 / 5 + 32 als 98.60000000000001 statt 98.6 heraus. Das ist IEEE-754-Verhalten, kein Bug. Nutzen Sie toFixed(2) für die Anzeige oder wechseln Sie zu einer Decimal-Bibliothek, falls in Ihrer Domäne die Präzision der letzten Stellen zählt.

Kann ich Temperaturen als Ganzzahlen speichern, um Fließkomma-Probleme zu vermeiden?

Ja — speichern Sie Dezi-Celsius (die Temperatur mal 10). 37,0°C wird zu 370, 22,5°C zu 225. Ganzzahl-Arithmetik ist exakt, und Sie dividieren nur an der Anzeigegrenze durch 10. Das Muster ist in Embedded-Systemen und in Time-Series-Datenbanken mit hohem Volumen verbreitet, wo Speicher und CPU zählen.

Wie gehe ich mit einheitenlosen Zahlen in einer API-Antwort um?

Gar nicht. Jedes Temperaturfeld sollte eine explizite Einheit tragen, entweder im Feldnamen (temp_celsius, temp_k) oder in einem begleitenden unit-Feld. Wenn Sie als Konsument mit einer API arbeiten, die das nicht tut, dokumentieren Sie die Annahme laut im Code und schreiben einen Vertragstest, der bricht, falls sich der API-Standard ändert.

Was ist der Siedepunkt von Wasser in allen vier Skalen?

100°C = 212°F = 373,15 K = 671,67°R, bei Standard-Atmosphärendruck (eine Atmosphäre, 101,325 kPa). Der Druck zählt: Auf Denvers Höhenlage siedet Wasser bei rund 95°C; auf dem Gipfel des Everest eher bei 71°C. Der Siedepunkt ist eine druckabhängige Größe, keine universelle Konstante.

Beeinflusst Temperatur Fließkomma-Berechnungen anders als andere Zahlen?

Nein — Temperaturwerte verhalten sich wie jede andere Fließkommazahl. Die praktische Falle: Die Faktoren 5/9 und 9/5 in den Umrechnungsformeln schleppen bei jedem Umrechnungsschritt einen Rundungsfehler ein. Für Kelvin-Werte zwischen 200 und 400 ist die Präzision mehr als ausreichend. Für sub-null Celsius-Werte nahe dem Rand darstellbarer Doubles bleibt sie ebenfalls in Ordnung. Die wirkliche Falle sind verkettete Umrechnungen, bei denen sich kleine Fehler aufaddieren — rechnen Sie einmal um und speichern Sie die kanonische Form.