Conversione temperatura online: Celsius, Fahrenheit, Kelvin

Lunedì pubblichi una dashboard meteo. Mercoledì un utente di Toronto apre un bug: l’app mostra la temperatura esterna come 284. L’endpoint di OpenWeatherMap restituiva Kelvin (il valore predefinito), la tua UI si aspettava Celsius e nessuno tra i due si è preoccupato di verificare. Una sottrazione mancante, uno screenshot rotto su Twitter.

Se ti servono solo le due formule e vuoi andare avanti:

Formula da Celsius a Fahrenheit: °F = °C × 9/5 + 32
Formula da Fahrenheit a Celsius: °C = (°F − 32) × 5/9
Da Celsius a Kelvin: K = °C + 273.15

Queste tre coprono circa il 90% di ciò che gli sviluppatori effettivamente usano. Il resto di questa guida è l’altro 10%: da dove viene 9/5, perché Kelvin non è mai negativo, come fare in modo che il sistema dei tipi rifiuti celsiusToFahrenheit(kelvinValue) a tempo di compilazione e come smettere di pubblicare il bug di Toronto. Puoi anche saltare la lettura e usare il nostro convertitore di temperatura quando ti serve subito un numero. Per unità non legate alla temperatura, vedi la più ampia guida completa alla conversione di unità.

Perché la temperatura è diversa dalle altre conversioni di unità

La maggior parte delle conversioni di unità è banalmente lineare attraverso lo zero. Un metro è 3.28084 piedi, punto. Raddoppia i metri, raddoppia i piedi. Zero metri sono zero piedi. Puoi costruire una libreria di conversione con una singola costante moltiplicativa per coppia e non pensarci mai più.

La temperatura rompe questo modello: le sue scale non condividono un punto zero. Celsius ancora il suo zero al punto di congelamento dell’acqua. Fahrenheit ancora il suo zero a una miscela salina del 1724. Kelvin ancora il suo zero al pavimento teorico della termodinamica. Per passare tra due qualsiasi, ti servono sia un fattore di scala sia un offset: la temperatura è una trasformazione affine, non lineare.

Questo ha una conseguenza pericolosa: i valori di temperatura non sono additivi come lo sono i valori di lunghezza o massa. 20°C + 20°C non è 40°C in nessun senso fisico. Non puoi “sommare due stanze” e ottenere una stanza più calda. Puoi sommare una differenza di temperatura a una temperatura, perché le differenze sono lineari. Questa distinzione è ciò che mandò in tilt l’incidente del vaccino Medeva del 2006 nel Regno Unito, dove un logger della catena del freddo farmaceutica confuse una lettura assoluta con un delta e marchiò migliaia di dosi come fuori specifica. Le quantità intensive come la temperatura hanno bisogno di questa protezione mentale: i numeri che condividono un’unità non condividono automaticamente l’algebra.

Le quattro scale di temperatura spiegate

Solo due scale contano per il codice quotidiano (Celsius, Fahrenheit), una terza conta per qualunque cosa scientifica (Kelvin) e la quarta compare in esattamente un posto: i libri di testo statunitensi di termodinamica e i codebase HVAC che ancora vi fanno riferimento.

Celsius (°C)

Anders Celsius pubblicò la sua scala nel 1742, originariamente con 0° all’ebollizione e 100° al congelamento, invertita rispetto a quella che usiamo oggi. L’orientamento moderno, con 0°C al punto di congelamento dell’acqua e 100°C al suo punto di ebollizione a un’atmosfera standard, arrivò poco dopo la sua morte. Oggi è l’unità derivata SI per la temperatura quotidiana e la scala predefinita in ogni paese tranne Stati Uniti, Bahamas, Belize, Isole Cayman e Liberia.

La ridefinizione SI del 2019 legò Celsius rigorosamente a Kelvin: 0°C è ora definito come esattamente 273.15 K. Il punto di congelamento dell’acqua, una volta la definizione, è ora una conseguenza misurata (cade su 0°C entro parti per milione, ma non è più l’ancora).

Fahrenheit (°F)

Daniel Gabriel Fahrenheit propose la sua scala nel 1724. Scelse 0°F come punto di congelamento di una specifica miscela salina, la temperatura più fredda che riusciva a riprodurre in modo affidabile in un inverno di Danzica, e 96°F come temperatura corporea. Una successiva ricalibrazione contro i punti di congelamento ed ebollizione dell’acqua pura spinse la temperatura corporea a 98.6°F e collocò il congelamento a 32°F e l’ebollizione a 212°F, un intervallo di 180 gradi.

Fahrenheit sopravvive negli Stati Uniti per meteo, cucina e uso medico. L’intervallo di 180 gradi tra congelamento ed ebollizione (rispetto ai 100 in Celsius) viene a volte difeso come “risoluzione più fine per le temperature ambiente”, un’affermazione marginale, ma che spiega perché i termostati americani sono marcati a passi di 1°F mentre quelli europei usano passi di 0.5°C.

Kelvin (K)

William Thomson, Lord Kelvin, propose una scala assoluta nel 1848. Il Kelvin moderno è l’unità base SI di temperatura. La ridefinizione SI del 2019 lega il kelvin alla costante di Boltzmann k_B = 1.380649 × 10⁻²³ J/K esattamente, rendendola una quantità definita anziché misurata.

Kelvin ha tre stranezze che gli sviluppatori dovrebbero conoscere:

Nessun simbolo di grado. Scrivi 300 K, non 300°K. Questa è la convenzione SI dal 1967.
Inizia allo zero assoluto. 0 K = −273.15°C. Non dovresti mai vedere un valore Kelvin negativo in dati validi; trattalo come un errore di input.
Stessa dimensione del grado di Celsius. Una variazione di 1 K equivale a una variazione di 1°C. Le differenze di temperatura sono intercambiabili tra le due; solo i valori assoluti differiscono per l’offset di 273.15.

Kelvin è la scelta giusta ogni volta che moltiplichi o dividi temperature: radiazione termica (T⁴), legge dei gas ideali, fisica del corpo nero. La divisione per un valore Celsius negativo o vicino a zero fa esplodere fisica che vuoi mantenere finita.

Rankine (°R)

William Rankine propose questa scala nel 1859 come l’equivalente Fahrenheit di Kelvin: una scala assoluta, zero allo zero assoluto, ma con gradi della stessa dimensione di Fahrenheit. 0°R = −459.67°F. 491.67°R = 0°C.

Incontrerai raramente Rankine al di fuori dell’ingegneria termodinamica statunitense — calcoli HVAC, raffinazione del petrolio, analisi della combustione di motori a razzo — dove la matematica richiede una scala assoluta ma i dati di input arrivano in Fahrenheit. La conversione è meccanica: °R = °F + 459.67, o equivalentemente °R = K × 9/5. La maggior parte del software di ingegneria moderno può rimanere internamente in Kelvin e convertire solo per la visualizzazione, che è ciò che raccomando quando puoi scegliere.

Formule di conversione della temperatura (tutte e sei le direzioni)

Sei direzioni, quattro scale, sei formule. In pratica memorizzi quelle centrate su Celsius e componi le altre.

Da Celsius a Fahrenheit e viceversa

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

Il fattore 9/5 è il rapporto tra gli intervalli delle due scale tra gli stessi due punti fisici di riferimento. Dal congelamento all’ebollizione, Fahrenheit copre 180 gradi (da 32 a 212); Celsius copre 100 (da 0 a 100). 180 / 100 = 9/5 = 1.8. Il + 32 è l’offset necessario per allineare gli zeri del punto di congelamento, perché lo zero di Fahrenheit si trova 32°F sotto lo zero di Celsius.

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

Da Celsius a Kelvin e viceversa

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

Nessun ridimensionamento, solo un offset. 273.15 è la distanza numerica dallo zero di Celsius (punto di congelamento dell’acqua) fino allo zero assoluto, misurata in gradi Celsius. Poiché Kelvin e Celsius condividono la stessa dimensione del grado, non c’è alcun moltiplicatore.

Da Fahrenheit a Kelvin e viceversa

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

Non esiste forma più breve: servono sia un cambio di scala sia un cambio di offset. Nel codice, è più pulito passare attraverso Celsius: k = cToK(fToC(f)). Scriverai meno, ti fiderai di più e il compilatore ottimizzerà comunque la composizione.

Conversioni Rankine

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

491.67 è 32 × 9/5 + 459.67, cioè il valore Rankine corrispondente a 0°C. Le comporrai raramente in pratica. Quando ti serve davvero Rankine, trattalo come “il gemello assoluto di Fahrenheit” e passa attraverso Fahrenheit o Kelvin.

Da dove viene 9/5? Una rapida derivazione

Le due scale sono legate da una funzione affine °F = a × °C + b. Per risolvere a e b, ti servono due punti di calibrazione noti. Congelamento ed ebollizione sono la coppia convenzionale:

Congelamento: 0°C ↔ 32°F
Ebollizione: 100°C ↔ 212°F

Sostituisci entrambi in °F = a × °C + b:

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

Ecco fatto: due equazioni lineari, due incognite, e l’intera conversione viene fuori. L’intuizione geometrica: immagina due termometri verticali fianco a fianco, uno in Celsius, uno in Fahrenheit. Il termometro Fahrenheit è allungato verticalmente (pendenza 9/5) e spostato verso l’alto (intercetta 32) rispetto a quello Celsius. Ogni altro valore di conversione si trova su quella linea allungata e spostata.

La stessa derivazione con (0°C, 273.15 K) e (100°C, 373.15 K) dà Celsius-Kelvin: pendenza 1, intercetta 273.15. La stessa derivazione con due punti di calibrazione qualsiasi non ambigui ti dà qualunque conversione affine. Niente nella temperatura è speciale matematicamente: la complessità sta interamente nel setup a due punti di ancoraggio di cui altre unità non hanno bisogno.

L’intersezione a −40°: un mnemonico utile

Esiste una temperatura in cui Celsius e Fahrenheit leggono lo stesso valore? Imposta °C = °F nella formula di conversione:

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

Quindi −40°C = −40°F. Esattamente un punto di incrocio, e si dà il caso che sia una temperatura reale che puoi incontrare a Yellowknife, Yakutsk o Fairbanks a gennaio. È anche una verifica mentale economica: ogni volta che stai stimando a occhio una conversione C↔F e il risultato cade vicino a −40, entrambi i numeri dovrebbero essere vicini tra loro. Se uno dice −40°C e l’altro −72°F, hai un bug di direzione.

Tengo l’elenco mnemonico completo attaccato accanto al monitor: congelamento (0 / 32), temperatura corporea (37 / 98.6), temperatura ambiente (20 / 68), ebollizione (100 / 212), −40 (−40 / −40). Cinque punti coprono quasi ogni verifica di sanità di cui ho bisogno.

Conversione di temperatura nel codice

Le formule sono banali. Farle bene in un codebase reale si riduce a due cose: impedire a un chiamante di passare Fahrenheit dove volevi Celsius, e rendere il comportamento in virgola mobile prevedibile ai confini (congelamento, zero assoluto, temperature del forno). Ogni esempio sotto è un programma completo ed eseguibile.

JavaScript / TypeScript

JavaScript puro ti dà conversioni funzionali immediatamente:

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

TypeScript ti permette di rendere la confusione di unità un errore di compilazione brandizzando il tipo numerico:

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); // Errore di compilazione: Temp<'F'> non è Temp<'C'>

I tipi brandizzati hanno costo runtime zero e ti costano una decina di righe di boilerplate. In cambio, il bug di Toronto del paragrafo iniziale diventa una sottolineatura rossa nel tuo editor.

Python

Le funzioni semplici vanno bene, ma un Enum più dataclass si ripaga la prima volta che logghi una temperatura:

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

Se stai elaborando dati scientifici dove 0.1 + 0.2 != 0.3 diventa un problema di audit, sostituisci float con decimal.Decimal. Il compromesso è la velocità (Decimal è circa 50x più lento) e il fatto che neanche 5/9 ha una rappresentazione decimale esatta, quindi serve Decimal(5) / Decimal(9) con un contesto controllato. Per la maggior parte delle pipeline di sensori, float più round(value, 2) al confine di visualizzazione è abbastanza.

Go

Il sistema dei tipi di Go ti permette di andare oltre TypeScript: un tipo float64 con nome non può essere mescolato silenziosamente con un altro tipo float64 con nome, anche se condividono la stessa rappresentazione runtime.

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          // errore di compilazione
    // fmt.Println(room.ToKelvin() + 1)   // errore di compilazione: Kelvin + int senza tipo richiede Kelvin(1)
}

Il costo è circa una riga per scala. Il vantaggio è che ToFahrenheit non può accettare un valore Kelvin per errore, e una funzione che prende Celsius rifiuterà un float64 grezzo al sito di chiamata.

Rust

Il pattern newtype di Rust ti dà le stesse garanzie di Go, più conversioni From/Into economiche:

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

Puoi aggiungere validazione sopra: un TryFrom<f64> for Kelvin che rifiuta i valori negativi restituisce Result<Kelvin, TemperatureError> e sposta il controllo al momento della costruzione. Stati invalidi non raggiungono mai la tua logica di business.

SQL (PostgreSQL)

Memorizza le temperature con vincoli CHECK e deriva unità alternative come colonne generate. In questo modo un valore Kelvin negativo è una violazione del vincolo all’inserimento, non un bug silenzioso nei dati tre query a valle.

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

-- Rifiutato all'inserimento:
-- INSERT INTO sensor_readings (celsius) VALUES (-300);
-- ERROR: new row for relation "sensor_readings" violates check constraint

GENERATED ALWAYS AS ... STORED baratta un po’ di disco con la velocità a tempo di query: leggi il valore, non lo ricalcoli. Per tabelle IoT ad alto volume, sostituisci STORED con una vista se la pressione sul disco conta più della latenza di lettura.

Gestire API meteo e IoT

Il bug più comune in produzione con la temperatura non è un errore di formula. È un disallineamento di unità tra ciò che un’API restituisce e ciò che la tua UI mostra. I provider che gli sviluppatori incontrano di più:

OpenWeatherMap restituisce Kelvin per impostazione predefinita. Passa units=metric per Celsius o units=imperial per Fahrenheit. Se dimentichi il parametro di query, ottieni Kelvin. Numeri come 284.15 che arrivano in un campo chiamato temp hanno ingannato abbastanza ingegneri da meritare un test di integrazione.

Open-Meteo restituisce Celsius per impostazione predefinita e accetta temperature_unit=fahrenheit. Nessuna opzione Kelvin: non è un’API scientifica.

Tomorrow.io e WeatherAPI usano metrico per impostazione predefinita ma restituiscono entrambe le scale nella stessa risposta sotto chiavi diverse. Leggi la chiave effettiva a cui si riferisce il tuo codice, non quella vicina.

Il pattern che uso per qualsiasi ingestione meteo o sensori:

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

// All'ingestione, ogni lettura porta esplicitamente la sua scala.
// Il livello UI non indovina mai: consuma celsius e formatta secondo la preferenza utente.

Da questo discendono due regole:

Ogni confine di ingestione registra la scala di origine. Niente numeri nudi che attraversano i confini dei moduli.
Il livello di visualizzazione è l’unico posto che converte all’unità preferita dall’utente.

La doppia conversione, dove due livelli “normalizzano” entrambi il numero, è l’altro bug frequente. Un team backend converte Kelvin in Celsius in scrittura. Un team frontend, ignaro, applica lo stesso - 273.15 in lettura. Gli utenti vedono temperature intorno a −251°C. La soluzione è un singolo proprietario per la normalizzazione, non più test.

Per IoT, i dati grezzi dei sensori spesso arrivano come conteggi ADC che devono essere convertiti in temperatura tramite una curva di calibrazione (per un termistore NTC da 10kΩ, significa l’equazione di Steinhart–Hart). Le conversioni di scala di temperatura avvengono dopo, sul valore già calibrato. Mescolare le due fasi è il modo per finire con numeri che sembrano temperature ma sono sballati del 30%.

Insidie comuni e come evitarle

Queste sei compaiono in codebase di produzione reali. Verifica la tua contro queste.

Usare la formula nella direzione sbagliata

Sintomo comune: un’app che mostra una febbre infantile a 37°C e poi la segnala come critica. Quel che è successo è che l’API ha restituito 37°F, qualcuno ha etichettato il valore celsius perché il nome della colonna lo diceva, e la logica della soglia medica ha confrontato contro una scala Celsius. Previeni questo facendo in modo che il tipo porti l’unità, non il nome della variabile.

Trattare la temperatura come estensiva

averageTemperature ha senso. sumTemperatures no. Se la tua aggregazione SQL ha SUM(temperature_c), qualcosa non va: probabilmente vuoi AVG o, in rari casi, una metrica integrata di gradi-giorno. La temperatura è una quantità intensiva; non sommarne due e aspettarti un risultato significativo.

Arrotondamento in virgola mobile

(37 * 9 / 5) + 32 in JavaScript dà 98.60000000000001, non 98.6. Ogni linguaggio che usa double IEEE 754 ha lo stesso comportamento. Opzioni:

Visualizza con .toFixed(2) (o l’equivalente del tuo linguaggio) e fermati lì.
Usa una libreria decimale (decimal.js, Python Decimal, BigDecimal) per accuratezza di livello audit.
Memorizza come interi in deci-gradi (370 invece di 37.0) e dividi solo alla visualizzazione.

Per la visualizzazione in una UI, toFixed(2) è la scelta giusta. Per un sistema di fatturazione o regolatorio dove gli errori di arrotondamento si accumulano, usa decimali.

Kelvin negativo nella validazione di input

Kelvin è non negativo per legge fisica. Un body di richiesta che contiene { "tempK": -10 } è sempre invalido. Imponi questo al confine — JSON schema, Pydantic, Zod, vincolo CHECK — non in profondità nella logica di business. L’unica eccezione, sistemi quantistici con “temperatura assoluta negativa”, non compare in nessuna API che probabilmente integrerai; se compare, già sai che lo fa.

Etichette di unità mancanti in UI e log

Una riga di log che dice sensor 42: 37 è inutile sei mesi dopo. È Celsius? Fahrenheit? Un conteggio ADC grezzo? Scrivi sempre sensor 42: 37°C o struttura il log come { "sensor": 42, "value": 37, "unit": "celsius" }. Lo spazio su disco costa poco; il triage di produzione alle tre del mattino no.

Confusione tra fuso orario e temperatura

Le app di viaggio rilasciano questo bug: quando un utente attraversa un fuso orario, il codice sposta servizievolmente ogni campo con timestamp, incluse le letture di temperatura. La temperatura non si cura dei fusi orari. Il timestamp su una lettura ha bisogno di logica di fuso; il valore della lettura no. Tienili in campi separati, passali attraverso pipeline di conversione separate.

Scorciatoie di calcolo mentale

Per quando non hai un convertitore aperto.

Da Celsius a Fahrenheit (approssimativo): raddoppialo, aggiungi 30. 20°C → 70°F (effettivo 68). 30°C → 90°F (effettivo 86). Accurato entro 2–3°F nell’intervallo 0–40°C, che copre ogni temperatura che sperimenti fuori da una fornace.

Da Fahrenheit a Celsius (approssimativo): sottrai 30, dimezza. 80°F → 25°C (effettivo 26.7). 60°F → 15°C (effettivo 15.6). Stessa banda di accuratezza.

Da Celsius a Kelvin: aggiungi 273 e arrotonda. Perdi 0.15 K, che è sotto la precisione del termometro per qualunque cosa fuori da un laboratorio di fisica.

Due ancore degne di memoria: 20°C = 68°F ≈ 293 K, e 100°C = 212°F = 373.15 K. Da queste due, l’interpolazione lineare ti porta abbastanza vicino per qualsiasi stima.

Le regole rapide e sporche coprono viaggi, abbozzi di cottura e previsioni meteo. Per qualsiasi cosa che vada in codice o in un’archiviazione regolatoria, usa le formule esatte, oppure apri il nostro strumento gratuito di conversione di temperatura e copia il valore preciso.

Tabelle di riferimento

Temperature quotidiane

Contesto	Celsius	Fahrenheit	Kelvin
Congelatore di casa	−18°C	0°F	255.15 K
Punto di congelamento	0°C	32°F	273.15 K
Frigorifero	4°C	39°F	277.15 K
Temperatura ambiente	20°C	68°F	293.15 K
Temperatura corporea	37°C	98.6°F	310.15 K
Soglia di febbre	38°C	100.4°F	311.15 K
Giornata estiva calda	35°C	95°F	308.15 K
Bollore dell’acqua	100°C	212°F	373.15 K

Conversioni cucina e forno

Preset del forno	Celsius	Fahrenheit
Basso / cottura lenta	125°C	257°F
Cottura tiepida	150°C	302°F
Cottura moderata	175°C	347°F
Cottura standard (torte)	180°C	356°F
Arrosto	190°C	374°F
Arrosto caldo	200°C	392°F
Arrosto alto	220°C	428°F
Crosta di pizza / pane	250°C	482°F

Le ricette americane arrotondano 350°F a 175°C o 180°C a seconda del libro di cucina; il valore esatto è 176.67°C. Entrambe le scelte funzionano: i forni di casa mantengono raramente la temperatura meglio di ±5°C comunque.

Estremi scientifici

Fenomeno	Kelvin	Celsius
Zero assoluto (pavimento teorico)	0 K	−273.15°C
Fondo cosmico a microonde	2.725 K	−270.425°C
Elio liquido (ebollizione, 1 atm)	4.2 K	−268.95°C
Transizione superconduttore (YBCO)	93 K	−180.15°C
Azoto liquido (ebollizione)	77 K	−196.15°C
Ombra dello spazio profondo	~40 K	~−233°C
Ghiaccio secco (sublimazione)	194.65 K	−78.5°C
Superficie del Sole	5.778 K	5.504,85°C
Nucleo del Sole	1.57×10⁷ K	1.57×10⁷ °C*
Plasma Tokamak (target ITER)	1.5×10⁸ K	~1.5×10⁸ °C*

*A queste grandezze, l’offset di 273.15 K è un errore di arrotondamento: Celsius e Kelvin leggono effettivamente identici.

FAQ

Qual è la formula per convertire Celsius in Fahrenheit?

Moltiplica Celsius per 9/5 (o 1.8), poi aggiungi 32: °F = °C × 9/5 + 32. Per esempio, 25°C × 1.8 + 32 = 77°F. Il moltiplicatore riflette il rapporto 180:100 tra gli intervalli delle due scale dal congelamento all’ebollizione, e il 32 allinea i loro diversi punti zero.

Qual è la formula per convertire Fahrenheit in Celsius?

Sottrai 32 dal valore Fahrenheit, poi moltiplica per 5/9: °C = (°F − 32) × 5/9. Per 72°F, il calcolo è (72 − 32) × 5/9 = 40 × 5/9 ≈ 22.22°C. Sottrai prima, moltiplica dopo: invertire l’ordine dà la risposta sbagliata.

A quale temperatura Celsius e Fahrenheit sono uguali?

Esattamente a −40 gradi. Imponendo °C = °F nella formula di conversione si ottiene °C = °C × 9/5 + 32, che si risolve in °C = −40. Questa è l’unica temperatura in cui le due scale leggono lo stesso numero, ed è un riferimento utile sia per ondate di freddo reali sia per bug di direzione di conversione.

Come converto 350°F in Celsius per la cottura?

350°F equivale a circa 176.67°C. Le ricette europee di solito arrotondano a 180°C, e molte tabelle di conversione da americano a metrico usano 175°C. Entrambi funzionano in un forno di casa: la stabilità della temperatura a quel livello è peggiore dell’errore di arrotondamento. Usa il nostro strumento convertitore di temperatura per valori esatti quando la precisione conta.

Quanto sono 100°F in Celsius?

100°F ≈ 37.78°C. Questo è appena sopra la temperatura corporea normale (37°C / 98.6°F) ed è spesso segnalato come l’inizio di una febbricola. Le linee guida mediche usano 38°C / 100.4°F come vera soglia di febbre, quindi 100°F è borderline ma non ancora clinicamente significativo.

Perché lo zero assoluto è −273.15°C e non semplicemente −273?

Perché la ridefinizione SI del 2019 ha fissato esattamente la costante di Boltzmann, rendendo −273.15°C il valore preciso calcolato dello zero assoluto anziché un’approssimazione arrotondata. Prima del 2019, lo zero Celsius era legato al punto triplo dell’acqua e lo 0.15 veniva dalla misura. Ora è esatto per definizione.

Quando dovrei usare Kelvin invece di Celsius nel codice?

Ogni volta che moltiplichi, dividi o elevi a potenza una temperatura: radiazione del corpo nero (T⁴), calcoli di gas ideali, velocità di reazione. Kelvin non diventa mai negativo, quindi la divisione resta stabile. Per differenze di temperatura, Celsius e Kelvin sono intercambiabili (una variazione di 5 gradi è la stessa in entrambi).

Rankine è ancora usato nel 2026?

Sì, ma in modo ristretto. L’ingegneria meccanica, HVAC e aerospaziale statunitense usa ancora Rankine per l’analisi di cicli termodinamici dove tutti gli altri input sono in Fahrenheit. Fuori da quei campi e fuori dagli Stati Uniti, è effettivamente morto. Se stai scrivendo software generale, supportare Rankine è un’assicurazione economica ma raramente portante.

Come converto la temperatura in una query SQL?

Inserisci la formula in linea o usa una colonna GENERATED ALWAYS AS. Esempio: SELECT celsius * 9.0 / 5.0 + 32.0 AS fahrenheit FROM readings. Il 9.0 e il 5.0 (non 9 e 5) forzano l’aritmetica in virgola mobile nella maggior parte dei dialetti; la divisione intera troncerà silenziosamente. Aggiungi un CHECK (celsius >= -273.15) per rifiutare valori senza senso all’inserimento.

Qual è il modo più facile per convertire Celsius in Fahrenheit a mente?

Raddoppia il valore Celsius e aggiungi 30. 22°C × 2 + 30 = 74°F (effettivo 71.6°F). Accurato entro circa 2°F per l’intervallo 0–30°C, che copre quasi tutte le letture meteo e indoor. Per l’inverso, sottrai 30 da Fahrenheit e dimezza.

Perché il mio convertitore di temperatura restituisce 98.599999 per 37°C?

Perché 9/5 = 1.8 non può essere rappresentato esattamente in virgola mobile binaria, quindi 37 × 9 / 5 + 32 esce come 98.60000000000001 anziché 98.6. Questo è il comportamento IEEE 754, non un bug. Usa toFixed(2) per la visualizzazione, o passa a una libreria decimale se la precisione delle cifre finali conta nel tuo dominio.

Posso memorizzare le temperature come interi per evitare problemi di virgola mobile?

Sì: memorizza deci-Celsius (la temperatura per 10). 37.0°C diventa 370, 22.5°C diventa 225. La matematica intera è esatta, e dividi per 10 solo al confine di visualizzazione. Questo pattern è comune nei sistemi embedded e nei database time-series ad alto volume dove disco e CPU contano.

Come gestisco numeri senza unità in una risposta API?

Non farlo. Ogni campo di temperatura dovrebbe portare un’unità esplicita, o nel nome del campo (temp_celsius, temp_k) o in un campo unit fratello. Se sei il consumatore e l’API non lo fornisce, documenta l’assunzione rumorosamente nel codice e scrivi un test contrattuale che si rompe se il default dell’API cambia.

Qual è il punto di ebollizione dell’acqua in tutte e quattro le scale?

100°C = 212°F = 373.15 K = 671.67°R, alla pressione atmosferica standard (un’atmosfera, 101.325 kPa). La pressione conta: all’altitudine di Denver, l’acqua bolle intorno a 95°C; in cima all’Everest, più vicino a 71°C. Il punto di ebollizione è una quantità dipendente dalla pressione, non una costante universale.

La temperatura influenza i calcoli in virgola mobile in modo diverso da altri numeri?

No: i valori di temperatura si comportano come qualsiasi altro numero in virgola mobile. L’insidia pratica è che i fattori 5/9 e 9/5 nelle formule di conversione introducono errore di arrotondamento a ogni passo di conversione. Per valori Kelvin nell’intervallo 200–400, la precisione è abbondante. Per valori Celsius sotto zero vicini al limite dei double rappresentabili, la precisione resta comunque buona. La vera insidia sono le conversioni a catena che accumulano piccoli errori: converti una volta e memorizza la forma canonica.