Conversión de temperatura: Celsius, Fahrenheit, Kelvin

Un lunes publicas un panel del clima. Para el miércoles, una usuaria de Toronto reporta un bug: la app muestra la temperatura exterior como 284. El endpoint de OpenWeatherMap devolvió Kelvin (el valor por defecto), tu UI esperaba Celsius y nada en medio se tomó la molestia de verificarlo. Una resta olvidada, una captura rota que circula por Twitter.

Si solo vienes por las dos fórmulas y quieres seguir adelante:

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

Con esas tres cubres aproximadamente el 90% de lo que los desarrolladores necesitan en la vida real. El resto de esta guía es el otro 10%: de dónde sale el 9/5, por qué Kelvin nunca es negativo, cómo hacer que tu sistema de tipos rechace celsiusToFahrenheit(kelvinValue) en tiempo de compilación y cómo dejar de enviar el bug de Toronto. Si solo te urge un número, usa nuestro convertidor de temperatura y listo. Para unidades que no son de temperatura, mira la guía completa de conversión de unidades.

Por qué la temperatura es diferente de otras conversiones de unidades

La mayoría de las conversiones de unidades son lineales y pasan por cero sin drama. Un metro son 3.28084 pies, y punto. Duplicas los metros, duplicas los pies. Cero metros, cero pies. Te alcanza una sola constante multiplicativa por par y ya no vuelves a pensarlo.

La temperatura rompe ese modelo en un aspecto clave: sus escalas no comparten un punto cero. Celsius ancla su cero en el punto de congelación del agua. Fahrenheit lo hace en una mezcla salina de la era de 1724. Kelvin, en el piso teórico de la termodinámica. Para pasar de una a otra hacen falta un factor de escalado y un desplazamiento: la temperatura es una transformación afín, no lineal.

La consecuencia práctica es concreta y peligrosa: los valores de temperatura no son aditivos como sí lo son los de longitud o masa. 20°C + 20°C no es 40°C en ningún sentido físico. No puedes “sumar dos habitaciones” y obtener una habitación más caliente. Lo que sí puedes hacer es sumar una diferencia de temperatura a una temperatura, porque las diferencias sí son lineales. Esa distinción fue la que detonó el incidente de la vacuna Medeva de 2006 en el Reino Unido, cuando un registrador de cadena de frío farmacéutica confundió una lectura absoluta con un delta y marcó miles de dosis como fuera de especificación. Las cantidades intensivas como la temperatura siempre requieren esta barrera mental: números que comparten unidad no comparten automáticamente el álgebra.

Las cuatro escalas de temperatura explicadas

Para el código del día a día importan dos escalas (Celsius y Fahrenheit), para cualquier cosa científica importa una tercera (Kelvin), y la cuarta aparece en exactamente un lugar: los libros de texto estadounidenses de termodinámica y las bases de código de HVAC que todavía los citan.

Celsius (°C)

Anders Celsius publicó su escala en 1742, originalmente con 0° en la ebullición y 100° en la congelación, invertida respecto a la que usamos hoy. La orientación moderna, con 0°C en el punto de congelación del agua y 100°C en su ebullición a una atmósfera estándar, llegó poco después de su muerte. Hoy es la unidad derivada del SI para la temperatura cotidiana y la escala por defecto en todos los países excepto Estados Unidos, Bahamas, Belice, Islas Caimán y Liberia.

La redefinición del SI de 2019 ligó Celsius a Kelvin de forma rigurosa: 0°C queda definido como exactamente 273.15 K. El punto de congelación del agua, que antes era la definición, ahora es una consecuencia medida (cae sobre 0°C con precisión de partes por millón, pero ya no es el anclaje).

Fahrenheit (°F)

Daniel Gabriel Fahrenheit propuso su escala en 1724. Fijó 0°F en el punto de congelación de una mezcla salina específica —la temperatura más fría que podía reproducir de forma confiable en un invierno en Danzig— y 96°F en la temperatura corporal. Una recalibración posterior contra los puntos de congelación y ebullición del agua pura corrió la temperatura corporal a 98.6°F y dejó la congelación en 32°F y la ebullición en 212°F, un intervalo de 180 grados.

Fahrenheit sobrevive en Estados Unidos para el clima, la cocina y el uso médico. El intervalo de 180 grados entre congelación y ebullición (contra 100 en Celsius) a veces se defiende como “resolución más fina para temperaturas ambientes”; es un argumento marginal, pero explica por qué los termostatos estadounidenses vienen marcados en pasos de 1°F y los europeos suelen ir en pasos de 0.5°C.

Kelvin (K)

William Thomson, Lord Kelvin, propuso una escala absoluta en 1848. El Kelvin moderno es la unidad base del SI para la temperatura. La redefinición del SI de 2019 ata el kelvin a la constante de Boltzmann k_B = 1.380649 × 10⁻²³ J/K de forma exacta, convirtiéndolo en una cantidad definida en vez de medida.

Kelvin trae tres peculiaridades que conviene conocer:

Sin símbolo de grado. Se escribe 300 K, no 300°K. Es la convención del SI desde 1967.
Arranca en el cero absoluto. 0 K = −273.15°C. Nunca deberías ver un Kelvin negativo en datos válidos; trátalo como error de entrada.
Mismo tamaño de grado que Celsius. Un cambio de 1 K equivale a un cambio de 1°C. Las diferencias de temperatura son intercambiables entre las dos; solo los valores absolutos difieren por el desplazamiento de 273.15.

Kelvin es la elección correcta cada vez que multiplicas, divides o elevas temperaturas: radiación térmica (T⁴), ley de los gases ideales, física del cuerpo negro. Dividir entre un Celsius negativo o cercano a cero hace explotar expresiones físicas que casi siempre quieres mantener finitas.

Rankine (°R)

William Rankine propuso esta escala en 1859 como el equivalente Fahrenheit de Kelvin: escala absoluta, cero en el cero absoluto, pero con grados del tamaño de Fahrenheit. 0°R = −459.67°F. 491.67°R = 0°C.

Casi nunca vas a cruzarte con Rankine fuera de la ingeniería termodinámica estadounidense —cálculos de HVAC, refinación de petróleo, análisis de combustión de motores de cohete— donde los cálculos piden una escala absoluta pero los datos de entrada vienen en Fahrenheit. La conversión es mecánica: °R = °F + 459.67, o equivalentemente °R = K × 9/5. Casi cualquier software de ingeniería moderno puede quedarse internamente en Kelvin y convertir solo al mostrar; cuando tengas la opción, eso es lo que conviene.

Fórmulas de conversión de temperatura (las seis direcciones)

Seis direcciones, cuatro escalas, seis fórmulas. En la práctica te memorizas las que giran en torno a Celsius y compones el resto.

Celsius a Fahrenheit y viceversa

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

El factor 9/5 es la proporción entre los intervalos de las dos escalas medidos sobre los mismos dos hitos físicos. De la congelación a la ebullición, Fahrenheit cubre 180 grados (32 a 212) y Celsius cubre 100 (0 a 100). 180 / 100 = 9/5 = 1.8. El + 32 es el desplazamiento que alinea los ceros del punto de congelación, porque el cero de Fahrenheit cae 32°F por debajo del cero de Celsius.

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

Celsius a Kelvin y viceversa

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

Sin escalado, solo un desplazamiento. 273.15 es la distancia numérica entre el cero de Celsius (punto de congelación del agua) y el cero absoluto, medida en grados Celsius. Como Kelvin y Celsius comparten el tamaño de grado, no hay multiplicador.

Fahrenheit a Kelvin y viceversa

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

No hay una forma más corta: hace falta un cambio de escala y un cambio de desplazamiento. En código, casi siempre sale más limpio pasar por Celsius: k = cToK(fToC(f)). Escribes menos, confías más en el resultado y el compilador acaba optimizando la composición de todas formas.

Conversiones de 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 es 32 × 9/5 + 459.67, es decir, el valor en Rankine correspondiente a 0°C. En la práctica casi nunca vas a componer estas a mano. Cuando necesites Rankine, trátalo como “el gemelo absoluto de Fahrenheit” y pasa por Fahrenheit o Kelvin.

¿De dónde viene el 9/5? Una derivación rápida

Las dos escalas están ligadas por una función afín °F = a × °C + b. Para despejar a y b hacen falta dos puntos de calibración conocidos. La congelación y la ebullición son el par convencional:

Congelación: 0°C ↔ 32°F
Ebullición: 100°C ↔ 212°F

Sustituye ambos en °F = a × °C + b:

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

Eso es todo: dos ecuaciones lineales, dos incógnitas, y toda la conversión cae sola. La intuición geométrica: imagina dos termómetros verticales lado a lado, uno en Celsius y otro en Fahrenheit. El de Fahrenheit está estirado verticalmente (pendiente 9/5) y desplazado hacia arriba (intercepto 32) respecto al de Celsius. Cualquier otro valor de conversión cae sobre esa misma recta estirada y desplazada.

La misma derivación con (0°C, 273.15 K) y (100°C, 373.15 K) te da Celsius a Kelvin: pendiente 1, intercepto 273.15. Con dos puntos de calibración inequívocos cualesquiera obtienes cualquier conversión afín. Matemáticamente, la temperatura no tiene nada de especial: la complicación está toda en la configuración de los dos puntos de anclaje que otras unidades no necesitan.

La intersección en −40°: un mnemónico útil

¿Existe una temperatura en la que Celsius y Fahrenheit marquen lo mismo? Iguala °C = °F en la fórmula de conversión:

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

Así que −40°C = −40°F. Exactamente un punto de cruce, y encima es una temperatura real que puedes medir en Yellowknife, Yakutsk o Fairbanks en enero. También sirve como verificación mental barata: si estimas a ojo una conversión C↔F y el resultado cae cerca de −40, los dos números deberían estar cerca entre sí. Si uno dice −40°C y el otro −72°F, tienes un bug de dirección.

Tengo el mnemónico completo pegado al monitor: congelación (0 / 32), temperatura corporal (37 / 98.6), temperatura ambiente (20 / 68), ebullición (100 / 212), −40 (−40 / −40). Cinco puntos bastan para casi cualquier verificación de cordura que necesito.

Conversión de temperatura en código

Las fórmulas son triviales. Lo que cuesta al llevarlas a una base de código real son dos cosas: evitar que un llamador pase Fahrenheit donde querías Celsius y hacer que el comportamiento en coma flotante sea predecible en los extremos (congelación, cero absoluto, temperaturas de horno). Todos los ejemplos de abajo son programas completos y ejecutables.

JavaScript / TypeScript

En JavaScript puro tienes conversiones funcionales de entrada:

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 te deja convertir la confusión de unidades en un error de compilación marcando el tipo number:

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); // Error de compilación: Temp<'F'> no es Temp<'C'>

Los tipos marcados (branded types) tienen costo cero en tiempo de ejecución y se pagan con unas diez líneas de código repetitivo. A cambio, el bug de Toronto del párrafo inicial se convierte en un subrayado rojo en tu editor.

Python

Con funciones sueltas te arreglas, pero un Enum más dataclass se paga solo la primera vez que tienes que registrar una temperatura en un log:

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"Escala desconocida: {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"Escala desconocida: {scale}")

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

Si procesas datos científicos donde 0.1 + 0.2 != 0.3 ya es un problema de auditoría, cambia float por decimal.Decimal. El trade-off es la velocidad (Decimal es unas 50 veces más lento) y que 5/9 tampoco tiene representación decimal exacta, así que vas a necesitar Decimal(5) / Decimal(9) con un contexto controlado. Para la mayoría de pipelines de sensores, float más round(value, 2) al mostrar basta y sobra.

Go

El sistema de tipos de Go te permite ir un paso más allá que TypeScript: un tipo float64 con nombre no puede mezclarse en silencio con otro tipo float64 con nombre, aunque compartan la misma representación en tiempo de ejecución.

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          // error de compilación
    // fmt.Println(room.ToKelvin() + 1)   // error de compilación: Kelvin + int sin tipo requiere Kelvin(1)
}

El costo es más o menos una línea por escala. El beneficio es que ToFahrenheit no puede aceptar un Kelvin por accidente, y una función que toma Celsius rechaza un float64 en bruto en el sitio de llamada.

Rust

El patrón newtype de Rust te da las mismas garantías que Go y añade conversiones From/Into baratas:

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

Encima puedes montar una capa de validación: un TryFrom<f64> for Kelvin que rechaza negativos devuelve Result<Kelvin, TemperatureError> y lleva la verificación al momento de construir. Los estados inválidos nunca llegan a la lógica de negocio.

SQL (PostgreSQL)

Guarda las temperaturas con restricciones CHECK y deriva las unidades alternativas como columnas generadas. Así, un Kelvin negativo es una violación de restricción al insertar, no un bug silencioso de datos tres consultas más adelante.

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

-- Rechazado al insertar:
-- INSERT INTO sensor_readings (celsius) VALUES (-300);
-- ERROR: new row for relation "sensor_readings" violates check constraint

GENERATED ALWAYS AS ... STORED cambia un poco de disco por velocidad en consulta: lees el valor, no lo recalculas. Para tablas IoT de alto volumen, cambia STORED por una vista si la presión de disco te pesa más que la latencia de lectura.

Cómo manejar APIs de clima y de IoT

El bug de temperatura más común en producción no es un error de fórmula. Es un desajuste de unidades entre lo que devuelve una API y lo que muestra tu UI. Un repaso rápido por los proveedores que más se usan:

OpenWeatherMap devuelve Kelvin por defecto. Pasa units=metric para Celsius o units=imperial para Fahrenheit. El detalle clave: si te olvidas del parámetro, obtienes Kelvin. Números como 284.15 llegando en un campo llamado temp han engañado a suficientes ingenieros como para justificar una prueba de integración.

Open-Meteo devuelve Celsius por defecto y acepta temperature_unit=fahrenheit. Sin opción de Kelvin: no es una API científica.

Tomorrow.io y WeatherAPI vienen con métrico por defecto, pero devuelven ambas escalas en la misma respuesta bajo claves distintas. Lee la clave real que tu código referencia, no la de al lado.

El patrón que uso para cualquier ingesta de datos de clima o de sensores:

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

// En la ingesta, cada lectura lleva explícitamente su escala.
// La capa de UI nunca adivina: consume celsius y formatea según la preferencia del usuario.

De ahí salen dos reglas:

Cada frontera de ingesta registra la escala de origen. Ningún número desnudo cruza las líneas entre módulos.
La capa de visualización es el único lugar que convierte a la unidad preferida del usuario.

La doble conversión —dos capas que cada una “normaliza” el mismo número— es el otro bug frecuente. El backend convierte Kelvin a Celsius al escribir. El frontend, sin saberlo, vuelve a aplicar - 273.15 al leer. Los usuarios ven temperaturas por −251°C. La solución es un único responsable de la normalización, no más pruebas.

En IoT, los datos crudos de sensor suelen llegar como un conteo ADC que se convierte a temperatura con una curva de calibración (para un termistor NTC de 10kΩ, eso quiere decir la ecuación de Steinhart–Hart). Las conversiones de escala de temperatura van después, sobre el valor ya calibrado. Mezclar las dos fases es como terminas con números que parecen temperatura pero están corridos un 30%.

Errores comunes y cómo evitarlos

Estos seis aparecen en bases de código reales en producción. Revisa si tienes alguno.

Usar la fórmula al revés

Síntoma clásico: una app que muestra 37°C de fiebre en un bebé y la marca como crítica. Lo que pasó: la API devolvió 37°F, alguien lo etiquetó como celsius porque así se llamaba la columna, y la lógica del umbral médico lo comparó contra una escala Celsius. Se evita haciendo que el tipo cargue la unidad, no el nombre de la variable.

Tratar la temperatura como cantidad extensiva

averageTemperature tiene sentido. sumTemperatures no. Si tu SQL de agregación dice SUM(temperature_c), algo anda mal: casi seguro querías AVG o, en casos raros, una métrica integrada de grados-día. La temperatura es una cantidad intensiva; no sumes dos esperando un resultado con sentido físico.

Redondeo de coma flotante

(37 * 9 / 5) + 32 en JavaScript da 98.60000000000001, no 98.6. Cualquier lenguaje con doubles IEEE 754 se comporta igual. Opciones:

Muestra con .toFixed(2) (o el equivalente en tu lenguaje) y déjalo ahí.
Usa una biblioteca decimal (decimal.js, Python Decimal, BigDecimal) para precisión nivel auditoría.
Guarda como enteros en deci-grados (370 en lugar de 37.0) y divide solo al mostrar.

Para una UI, toFixed(2) casi siempre es correcto. Para un sistema de facturación o regulatorio donde los errores de redondeo se acumulan, ve por decimales.

Kelvin negativo en la validación de entradas

Kelvin es no negativo por ley física. Un cuerpo de petición con { "tempK": -10 } siempre es inválido. Imponlo en la frontera —JSON schema, Pydantic, Zod, restricción CHECK— no en lo profundo de la lógica de negocio. La única excepción, los sistemas cuánticos con “temperatura absoluta negativa”, no aparece en ninguna API con la que probablemente te integres; si aparece, sabrás de sobra que aparece.

Sin etiquetas de unidad en UI y logs

Una línea de log que dice sensor 42: 37 es inútil seis meses después. ¿Es Celsius? ¿Fahrenheit? ¿Un conteo ADC crudo? Escribe siempre sensor 42: 37°C o estructura el log como { "sensor": 42, "value": 37, "unit": "celsius" }. El disco es barato; triar un incidente en producción a las tres de la madrugada no lo es.

Confundir zona horaria con temperatura

Las apps de viajes sueltan este bug de vez en cuando: cuando el usuario cruza una zona horaria, el código amablemente desplaza cada campo con marca de tiempo, incluidas las lecturas de temperatura. A la temperatura no le importan las zonas horarias. La marca de tiempo de una lectura necesita lógica de zona horaria; el valor de la lectura no. Manténlos en campos separados y pásalos por pipelines de conversión separados.

Atajos de cálculo mental

Para cuando no tienes un convertidor a mano.

Celsius a Fahrenheit (aproximado): duplica y suma 30. 20°C → 70°F (real 68). 30°C → 90°F (real 86). Precisión dentro de 2–3°F en el rango 0–40°C, que cubre casi cualquier temperatura que vas a sentir fuera de un horno cerámico.

Fahrenheit a Celsius (aproximado): resta 30, divide entre dos. 80°F → 25°C (real 26.7). 60°F → 15°C (real 15.6). Misma banda de precisión.

Celsius a Kelvin: suma 273 y redondea. Pierdes 0.15 K, por debajo de la precisión de un termómetro para cualquier cosa fuera de un laboratorio de física.

Dos anclajes que vale la pena memorizar: 20°C = 68°F ≈ 293 K, y 100°C = 212°F = 373.15 K. A partir de esos dos, interpolas linealmente y te queda suficiente para cualquier estimación.

Las reglas rápidas y sucias cubren viajes, aproximaciones de cocina y pronósticos del clima. Para cualquier cosa que vaya a código o a una presentación regulatoria, ve con las fórmulas exactas o abre nuestra herramienta gratuita de conversión de temperatura y copia el valor preciso.

Tablas de referencia

Temperaturas cotidianas

Contexto	Celsius	Fahrenheit	Kelvin
Congelador doméstico	−18°C	0°F	255.15 K
Punto de congelación	0°C	32°F	273.15 K
Refrigerador	4°C	39°F	277.15 K
Temperatura ambiente	20°C	68°F	293.15 K
Temperatura corporal	37°C	98.6°F	310.15 K
Umbral de fiebre	38°C	100.4°F	311.15 K
Día caluroso de verano	35°C	95°F	308.15 K
Ebullición del agua	100°C	212°F	373.15 K

Conversiones de cocina y horno

Preajuste de horno	Celsius	Fahrenheit
Bajo / cocción lenta	125°C	257°F
Horneado tibio	150°C	302°F
Horneado moderado	175°C	347°F
Horneado estándar (pasteles)	180°C	356°F
Asado	190°C	374°F
Asado caliente	200°C	392°F
Asado alto	220°C	428°F
Pizza / corteza de pan	250°C	482°F

Las recetas estadounidenses redondean 350°F a 175°C o 180°C según el libro de cocina; el valor exacto es 176.67°C. Cualquiera de las dos funciona: un horno doméstico rara vez mantiene la temperatura con una precisión mejor que ±5°C.

Extremos científicos

Fenómeno	Kelvin	Celsius
Cero absoluto (piso teórico)	0 K	−273.15°C
Fondo cósmico de microondas	2.725 K	−270.425°C
Helio líquido (ebullición, 1 atm)	4.2 K	−268.95°C
Transición superconductora (YBCO)	93 K	−180.15°C
Nitrógeno líquido (ebullición)	77 K	−196.15°C
Sombra del espacio profundo	~40 K	~−233°C
Hielo seco (sublimación)	194.65 K	−78.5°C
Superficie del Sol	5,778 K	5,504.85°C
Núcleo del Sol	1.57×10⁷ K	1.57×10⁷ °C*
Plasma Tokamak (objetivo ITER)	1.5×10⁸ K	~1.5×10⁸ °C*

*A estas magnitudes el desplazamiento de 273.15 K es ruido de redondeo: Celsius y Kelvin marcan prácticamente lo mismo.

Preguntas frecuentes

¿Cuál es la fórmula para convertir Celsius a Fahrenheit?

Multiplica Celsius por 9/5 (o 1.8) y suma 32: °F = °C × 9/5 + 32. Por ejemplo, 25°C × 1.8 + 32 = 77°F. El multiplicador refleja la proporción 180:100 entre los intervalos de las dos escalas desde la congelación hasta la ebullición, y el 32 alinea sus puntos cero distintos.

¿Cuál es la fórmula para convertir Fahrenheit a Celsius?

Resta 32 al valor Fahrenheit y multiplica por 5/9: °C = (°F − 32) × 5/9. Para 72°F, el cálculo queda (72 − 32) × 5/9 = 40 × 5/9 ≈ 22.22°C. Primero resta y después multiplica: invertir el orden te da una respuesta equivocada.

¿A qué temperatura son iguales Celsius y Fahrenheit?

A exactamente −40 grados. Al igualar °C = °F en la fórmula de conversión sale °C = °C × 9/5 + 32, que se resuelve en °C = −40. Es la única temperatura a la que las dos escalas marcan el mismo número, y un hito útil para sanity-check tanto en olas de frío reales como en bugs de dirección de conversión.

¿Cómo convierto 350°F a Celsius para hornear?

350°F son más o menos 176.67°C. Las recetas europeas suelen redondear a 180°C, y muchas tablas de americano a métrico usan 175°C. Cualquiera de los dos funciona en un horno doméstico: la estabilidad de temperatura en ese rango es peor que el error de redondeo. Usa nuestra herramienta de conversión de temperatura para valores exactos cuando la precisión importe.

¿Cuánto es 100°F en Celsius?

100°F ≈ 37.78°C. Queda justo por encima de la temperatura corporal normal (37°C / 98.6°F) y se suele señalar como el inicio de una fiebre leve. Las guías médicas suelen usar 38°C / 100.4°F como umbral real de fiebre, así que 100°F es limítrofe pero todavía no clínicamente significativo.

¿Por qué el cero absoluto es −273.15°C y no solo −273?

Porque la redefinición del SI de 2019 fijó la constante de Boltzmann de forma exacta, y eso hace que −273.15°C sea el valor calculado preciso del cero absoluto en lugar de una aproximación redondeada. Antes de 2019, el cero de Celsius estaba atado al punto triple del agua y el 0.15 venía de la medición. Hoy es exacto por definición.

¿Cuándo debería usar Kelvin en lugar de Celsius en el código?

Cada vez que multipliques, dividas o eleves una temperatura a una potencia: radiación del cuerpo negro (T⁴), cálculos de gas ideal, tasas de reacción. Kelvin nunca es negativo, así que la división se mantiene estable. Para diferencias de temperatura, Celsius y Kelvin son intercambiables (un cambio de 5 grados es el mismo en ambas).

¿Se sigue usando Rankine en 2026?

Sí, pero de forma acotada. La ingeniería mecánica, de HVAC y aeroespacial en Estados Unidos todavía usa Rankine para el análisis de ciclos termodinámicos donde todas las demás entradas están en Fahrenheit. Fuera de esos campos y fuera de Estados Unidos, está efectivamente muerto. Si escribes software de propósito general, soportar Rankine es un seguro barato pero rara vez crítico.

¿Cómo convierto temperatura en una consulta SQL?

Mete la fórmula en línea o usa una columna GENERATED ALWAYS AS. Ejemplo: SELECT celsius * 9.0 / 5.0 + 32.0 AS fahrenheit FROM readings. Los 9.0 y 5.0 (no 9 y 5) fuerzan aritmética de coma flotante en la mayoría de los dialectos; la división entera trunca sin avisar. Añade un CHECK (celsius >= -273.15) para rechazar valores sin sentido al insertar.

¿Cuál es la forma más fácil de convertir Celsius a Fahrenheit mentalmente?

Duplica el valor Celsius y suma 30. 22°C × 2 + 30 = 74°F (real 71.6°F). Precisión dentro de unos 2°F en el rango 0–30°C, que cubre casi todas las temperaturas de clima y de interiores. Para el sentido inverso, resta 30 a Fahrenheit y divide entre dos.

¿Por qué mi convertidor de temperatura devuelve 98.599999 para 37°C?

Porque 9/5 = 1.8 no puede representarse exacto en coma flotante binaria, así que 37 × 9 / 5 + 32 sale como 98.60000000000001 en lugar de 98.6. Es comportamiento de IEEE 754, no un bug. Usa toFixed(2) para mostrar, o pásate a una biblioteca decimal si la precisión de los últimos dígitos pesa en tu dominio.

¿Puedo almacenar temperaturas como enteros para evitar problemas de coma flotante?

Sí: guarda deci-Celsius (la temperatura por 10). 37.0°C queda como 370 y 22.5°C como 225. La matemática entera es exacta, y divides entre 10 solo al mostrar. Es un patrón habitual en sistemas embebidos y bases de datos de series temporales de alto volumen donde el disco y la CPU importan.

¿Cómo manejo números sin unidad en una respuesta de API?

No lo hagas. Cada campo de temperatura tiene que llevar unidad explícita, ya sea en el nombre (temp_celsius, temp_k) o en un campo hermano unit. Si tú eres el consumidor y la API no lo aporta, documenta la suposición de forma muy visible en el código y escribe un test de contrato que falle si el valor por defecto de la API cambia.

¿Cuál es el punto de ebullición del agua en las cuatro escalas?

100°C = 212°F = 373.15 K = 671.67°R, a presión atmosférica estándar (una atmósfera, 101.325 kPa). La presión importa: a la altitud de Denver el agua hierve cerca de 95°C; en la cima del Everest, alrededor de 71°C. El punto de ebullición depende de la presión; no es una constante universal.

¿La temperatura afecta a los cálculos de coma flotante de forma distinta a otros números?

No: los valores de temperatura se comportan igual que cualquier otro número de coma flotante. El problema práctico es que los factores 5/9 y 9/5 de las fórmulas de conversión meten error de redondeo en cada paso. Para valores Kelvin en el rango 200–400, precisión de sobra. Para Celsius bajo cero cerca del borde de los doubles representables, la precisión también aguanta bien. El riesgo real son las conversiones encadenadas que acumulan errorcitos: convierte una vez y guarda la forma canónica.