В понедельник вы выкатываете дашборд погоды. К среде пользователь из Торонто заводит баг: приложение показывает уличную температуру 284. Эндпоинт OpenWeatherMap вернул Кельвин (по умолчанию), интерфейс ожидал Цельсий, и ничему между этим не хватило сил проверить. Одно пропущенное вычитание — один сломанный скриншот в Twitter.
Если нужны просто две формулы и идём дальше:
- Цельсий в Фаренгейт:
°F = °C × 9/5 + 32 - Фаренгейт в Цельсий:
°C = (°F − 32) × 5/9 - Цельсий в Кельвин:
K = °C + 273,15
Эти три покрывают примерно 90% того, что разработчикам реально нужно. Остальное — это другие 10%: откуда берётся 9/5, почему Кельвин никогда не отрицателен, как заставить систему типов отвергать celsiusToFahrenheit(kelvinValue) на этапе компиляции и как перестать выкатывать «торонтовский баг». Можно вовсе пропустить чтение и пользоваться конвертером температуры, когда нужно число прямо сейчас. Для не-температурных единиц смотрите более широкое руководство по конвертации единиц.
Почему температура отличается от других конвертаций единиц
Большинство конвертаций единиц тривиально линейны через ноль. Метр — это 3,28084 фута, точка. Удвоили метры — удвоились футы. Ноль метров — ноль футов. Можно построить библиотеку конвертации с одной мультипликативной константой на пару единиц и больше об этом не думать.
С температурой эта модель ломается: у её шкал нет общей точки нуля. Цельсий привязывает свой ноль к точке замерзания воды. Фаренгейт привязывает свой ноль к смеси соляного раствора эпохи 1724 года. Кельвин привязывает свой ноль к теоретическому полу термодинамики. Чтобы ходить между любыми двумя, нужны и масштабный коэффициент, и смещение — температура это аффинное преобразование, а не линейное.
У этого опасное следствие: значения температуры не аддитивны так, как значения длины или массы. 20°C + 20°C физически не 40°C. Нельзя «сложить две комнаты» и получить более тёплую комнату. Можно прибавить разность температур к температуре, потому что разности линейны. Именно это различие подкосило инцидент с вакциной Medeva в Великобритании в 2006-м, когда логгер холодовой цепи перепутал абсолютное показание с дельтой и пометил тысячи доз как вышедшие из спецификации. Интенсивные величины вроде температуры требуют этого ментального ограждения: одинаковая единица не значит одинаковая алгебра.
Четыре температурные шкалы
Только две шкалы важны для повседневного кода (Цельсий, Фаренгейт), третья — для всего научного (Кельвин), четвёртая встречается ровно в одном месте: американские учебники термодинамики и кодовая база HVAC, всё ещё на них опирающаяся.
Цельсий (°C)
Андерс Цельсий опубликовал свою шкалу в 1742 году, изначально с 0° на кипении и 100° на замерзании — наоборот к тому, что мы используем сейчас. Современная ориентация, с 0°C в точке замерзания воды и 100°C в точке кипения при одной стандартной атмосфере, появилась вскоре после его смерти. Сегодня это SI-производная единица повседневной температуры и шкала по умолчанию в каждой стране, кроме США, Багам, Белиза, Каймановых островов и Либерии.
Переопределение SI 2019 года жёстко связало Цельсий с Кельвином: 0°C теперь определён как ровно 273,15 K. Точка замерзания воды, когда-то определение, теперь измеренное следствие (попадает на 0°C с точностью до миллионных, но больше не якорь).
Фаренгейт (°F)
Даниэль Габриэль Фаренгейт предложил свою шкалу в 1724 году. Он выбрал 0°F как точку замерзания специфической смеси соляного раствора — самую холодную температуру, которую он мог надёжно воспроизвести в датской зиме, — и 96°F как температуру тела. Позднейшая перекалибровка против точек замерзания и кипения чистой воды сместила температуру тела до 98,6°F и поставила замерзание на 32°F и кипение на 212°F — диапазон 180 градусов.
Фаренгейт сохранился в США для погоды, кулинарии и медицины. Диапазон 180 градусов между замерзанием и кипением (против 100 у Цельсия) иногда защищают как «более тонкое разрешение для бытовых температур» — спорное утверждение, но оно объясняет, почему американские термостаты размечены шагом 1°F, а европейские — 0,5°C.
Кельвин (K)
Уильям Томсон, лорд Кельвин, предложил абсолютную шкалу в 1848 году. Современный Кельвин — это базовая единица температуры в SI. Переопределение SI 2019 года связывает кельвин точно с постоянной Больцмана k_B = 1,380649 × 10⁻²³ J/K, делая его величиной по определению, а не измеренной.
У Кельвина три особенности, которые разработчик должен знать:
- Без знака градуса. Пишите
300 K, не300°K. Это конвенция SI с 1967 года. - Стартует от абсолютного нуля.
0 K = −273,15°C. Отрицательное значение Кельвина в валидных данных встречаться не должно — относитесь к нему как к ошибке ввода. - Тот же размер градуса, что у Цельсия. Изменение в 1 K равно изменению в 1°C. Температурные разности взаимозаменяемы между двумя; различаются только абсолютные значения на смещение 273,15.
Кельвин — правильный выбор всякий раз, когда вы умножаете или делите температуры — тепловое излучение (T⁴), уравнение состояния идеального газа, физика чёрного тела. Деление на отрицательное или околонулевое значение Цельсия взрывает физику, которую вы хотите сохранить конечной.
Ранкин (°R)
Уильям Ранкин предложил эту шкалу в 1859 году как фаренгейтовый эквивалент Кельвина: абсолютная шкала, ноль на абсолютном нуле, но с градусами размером с фаренгейтовы. 0°R = −459,67°F. 491,67°R = 0°C.
Ранкин редко встречается за пределами американской термодинамической инженерии — расчётов HVAC, нефтепереработки, анализа сгорания ракетных двигателей, — где математике нужна абсолютная шкала, а входные данные приходят в Фаренгейте. Перевод механический: °R = °F + 459,67, или эквивалентно °R = K × 9/5. Большинство современных инженерных пакетов могут оставаться в Кельвине внутри и переводить только для отображения — так и рекомендую при наличии выбора.
Формулы конвертации температуры (все шесть направлений)
Шесть направлений, четыре шкалы, шесть формул. На практике запоминают центрированные на Цельсии и собирают остальное.
Цельсий ↔ Фаренгейт
°F = °C × 9/5 + 32
°C = (°F − 32) × 5/9Коэффициент 9/5 — это отношение диапазонов двух шкал между одинаковыми физическими ориентирами. От замерзания до кипения Фаренгейт покрывает 180 градусов (32 → 212); Цельсий — 100 (0 → 100). 180 / 100 = 9/5 = 1,8. + 32 — это смещение, нужное для выравнивания нулей точки замерзания, потому что ноль Фаренгейта сидит на 32°F ниже нуля Цельсия.
Разбор примера: °F = 25 × 9/5 + 32 = 45 + 32 = 77°F.
Цельсий ↔ Кельвин
K = °C + 273,15
°C = K − 273,15Без масштабирования, только смещение. 273,15 — это численное расстояние от нуля Цельсия (точки замерзания воды) до абсолютного нуля, измеренное в градусах Цельсия. Поскольку Кельвин и Цельсий имеют тот же размер градуса, множителя нет.
Фаренгейт ↔ Кельвин
K = (°F − 32) × 5/9 + 273,15
°F = (K − 273,15) × 9/5 + 32Короче не получится — нужны и смена масштаба, и смена смещения. В коде чище идти через Цельсий: k = cToK(fToC(f)). Напишете меньше, доверяете больше, а компилятор всё равно соптимизирует композицию.
Конвертации Ранкина
°R = °F + 459,67
°F = °R − 459,67
°R = K × 9/5
K = °R × 5/9
°R = °C × 9/5 + 491,67491,67 — это 32 × 9/5 + 459,67, то есть значение Ранкина, соответствующее 0°C. Соберёте редко на практике. Когда Ранкин действительно нужен, относитесь к нему как к «абсолютному близнецу Фаренгейта» и идите через Фаренгейт или Кельвин.
Откуда берётся 9/5? Быстрый вывод
Шкалы связаны аффинной функцией °F = a × °C + b. Чтобы решить относительно a и b, нужны две известные точки калибровки. Замерзание и кипение — обычная пара:
- Замерзание:
0°C ↔ 32°F - Кипение:
100°C ↔ 212°F
Подставляем обе в °F = a × °C + b:
32 = a × 0 + b → b = 32
212 = a × 100 + 32 → a = (212 − 32) / 100 = 180 / 100 = 9/5Вот и всё — два линейных уравнения, два неизвестных, и вся конвертация выпадает. Геометрическая интуиция: представьте два вертикальных термометра рядом, один в Цельсии, второй в Фаренгейте. Фаренгейтовый растянут вертикально (наклон 9/5) и смещён вверх (свободный член 32) относительно Цельсиевого. Любое другое значение конвертации лежит на этой растянутой и смещённой прямой.
Тот же вывод с (0°C, 273,15 K) и (100°C, 373,15 K) даёт Цельсий → Кельвин: наклон 1, свободный член 273,15. Тот же вывод с любыми двумя однозначными точками калибровки даёт любую аффинную конвертацию. Ничего особенного в температуре математически нет — сложность вся в постановке с двумя точками привязки, которая не нужна другим типам единиц.
Пересечение −40°: полезная мнемоника
Есть ли температура, где Цельсий и Фаренгейт читаются одинаково? Положим °C = °F в формулу конвертации:
°C = °C × 9/5 + 32
°C − °C × 9/5 = 32
°C × (1 − 9/5) = 32
°C × (−4/5) = 32
°C = −40Итак, −40°C = −40°F. Ровно одна точка пересечения, и это реальная температура, которую можно встретить в Йеллоунайфе, Якутске или Фэрбанксе в январе. Это и дешёвый ментальный чек: всякий раз, когда оцениваете C↔F и результат садится около −40, оба числа должны быть близки друг к другу. Если одно говорит −40°C, а другое −72°F, у вас баг направления.
Полный мнемонический список приклеен у меня рядом с монитором: замерзание (0 / 32), температура тела (37 / 98,6), комнатная (20 / 68), кипение (100 / 212), −40 (−40 / −40). Пять точек закрывают почти любой нужный sanity-чек.
Конвертация температуры в коде
Формулы тривиальны. Получить их корректно в реальной кодовой базе — это про две вещи: не дать вызывающему передать Фаренгейт там, где ожидался Цельсий, и сделать поведение чисел с плавающей точкой предсказуемым на границах (замерзание, абсолютный ноль, температуры духовки). Каждый пример ниже — полная запускаемая программа.
JavaScript / TypeScript
Чистый JavaScript сразу даёт функциональные конвертации:
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.85TypeScript позволяет сделать путаницу единиц ошибкой компиляции, заклеймив тип числа:
type Scale = 'C' | 'F' | 'K' | 'R';
type Temp<S extends Scale> = number & { readonly __scale: S };
const t = <S extends Scale>(value: number, _scale: S): Temp<S> =>
value as Temp<S>;
const cToF = (c: Temp<'C'>): Temp<'F'> => t(c * 9 / 5 + 32, 'F');
const fToC = (f: Temp<'F'>): Temp<'C'> => t((f - 32) * 5 / 9, 'C');
const indoor = t(22, 'C');
const outdoor = cToF(indoor); // OK: Temp<'F'>
// const broken = cToF(outdoor); // Compile error: Temp<'F'> is not Temp<'C'>Branded-типы стоят нуля в рантайме и около десятка строк boilerplate. В обмен «торонтовский баг» из вступления превращается в красное подчёркивание в редакторе.
Python
Чистые функции работают, но Enum плюс dataclass окупаются с первого раза, как залогируете температуру:
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Если вы перетираете научные данные, где 0.1 + 0.2 != 0.3 становится аудит-проблемой, замените float на decimal.Decimal. Цена — скорость (Decimal примерно в 50× медленнее) и тот факт, что у 5/9 тоже нет точного десятичного представления, поэтому понадобится Decimal(5) / Decimal(9) в управляемом контексте. Для большинства sensor-пайплайнов float плюс round(value, 2) на границе отображения хватает.
Go
Система типов Go идёт дальше TypeScript: именованный тип float64 нельзя бесшумно смешать с другим именованным float64, даже если они делят то же 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 // compile error
// fmt.Println(room.ToKelvin() + 1) // compile error: Kelvin + untyped int needs Kelvin(1)
}Цена — примерно одна строка на шкалу. Выгода в том, что ToFahrenheit не может случайно принять Kelvin, а функция, принимающая Celsius, откажется от сырого float64 в точке вызова.
Rust
Newtype-паттерн Rust даёт те же гарантии, что Go, плюс дешёвые From/Into-конверсии:
#[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)
}Сверху можно навесить валидацию: TryFrom<f64> for Kelvin, отвергающий отрицательные, возвращает Result<Kelvin, TemperatureError> и переносит проверку на момент конструирования. Невалидные состояния не доходят до бизнес-логики.
SQL (PostgreSQL)
Храните температуры с CHECK-ограничениями и выводите альтернативные единицы как сгенерированные колонки. Тогда отрицательное значение Кельвина — это нарушение constraint при insert, а не тихий баг данных через три запроса.
CREATE OR REPLACE FUNCTION c_to_f(c numeric) RETURNS numeric AS $$
SELECT c * 9.0 / 5.0 + 32.0;
$$ LANGUAGE SQL IMMUTABLE;
CREATE OR REPLACE FUNCTION c_to_k(c numeric) RETURNS numeric AS $$
SELECT c + 273.15;
$$ LANGUAGE SQL IMMUTABLE;
CREATE TABLE sensor_readings (
id bigserial PRIMARY KEY,
recorded_at timestamptz NOT NULL DEFAULT now(),
celsius numeric(6, 2) NOT NULL,
fahrenheit numeric(6, 2) GENERATED ALWAYS AS (c_to_f(celsius)) STORED,
kelvin numeric(6, 2) GENERATED ALWAYS AS (c_to_k(celsius)) STORED,
CONSTRAINT kelvin_non_negative CHECK (celsius >= -273.15)
);
INSERT INTO sensor_readings (celsius) VALUES (22.5), (0), (100);
SELECT celsius, fahrenheit, kelvin FROM sensor_readings;
-- 22.50 | 72.50 | 295.65
-- 0.00 | 32.00 | 273.15
-- 100.00| 212.00 | 373.15
-- Rejected at insert time:
-- INSERT INTO sensor_readings (celsius) VALUES (-300);
-- ERROR: new row for relation "sensor_readings" violates check constraintGENERATED ALWAYS AS … STORED обменивает немного диска на скорость запроса — значение читается, а не пересчитывается. Для высоконагруженных IoT-таблиц замените STORED на view, если давление по диску важнее задержки чтения.
Работа с погодными и IoT API
Самый частый прод-баг с температурой — не ошибка в формуле. Это рассогласование единиц между тем, что возвращает API, и тем, что отображает интерфейс. Поставщики, к которым обращаются чаще всего:
OpenWeatherMap возвращает Кельвин по умолчанию. Передайте units=metric для Цельсия или units=imperial для Фаренгейта. Забудете параметр запроса — получите Кельвин. Числа вроде 284,15 в поле temp обмануют достаточно инженеров, чтобы того стоил интеграционный тест.
Open-Meteo возвращает Цельсий по умолчанию и принимает temperature_unit=fahrenheit. Кельвина нет — это не научный API.
Tomorrow.io и WeatherAPI по умолчанию метрические, но возвращают обе шкалы в одном ответе под разными ключами. Читайте именно тот ключ, на который ссылается код, а не соседний.
Паттерн, который применяю для любой погодной или сенсорной приёмки:
type Reading = {
value: number;
scale: 'C' | 'F' | 'K';
source: string;
};
function normalise(raw: Reading): number /* celsius */ {
switch (raw.scale) {
case 'C': return raw.value;
case 'F': return (raw.value - 32) * 5 / 9;
case 'K': return raw.value - 273.15;
}
}
// At ingestion, every reading carries its scale explicitly.
// The UI layer never guesses — it consumes celsius and formats per user preference.Из этого вытекают два правила:
- На каждой границе приёмки записывается исходная шкала. Никаких голых чисел через границы модулей.
- Слой отображения — единственное место, где идёт конверсия в предпочитаемую пользователем единицу.
Двойная конверсия — когда два слоя «нормализуют» одно число — другой частый баг. Backend-команда переводит Кельвин в Цельсий на запись. Frontend-команда, не зная об этом, применяет тот же - 273,15 на чтение. Пользователи видят температуры около −251°C. Решение — единственный владелец нормализации, а не больше тестов.
Для IoT сырые данные сенсора часто приходят как ADC-отсчёт, который надо перевести в температуру через калибровочную кривую (для NTC-термистора 10kΩ это уравнение Стейнхарта–Харта). Конвертации температурных шкал происходят после того, на уже откалиброванном значении. Смешивание двух фаз — это как получить числа, формой похожие на температуру, но смещённые на 30%.
Типичные подводные камни
Эти шесть встречаются в реальных production-кодах. Сверьте свой:
Неправильное направление формулы
Типичный симптом: приложение показывает 37°C детской лихорадки и тут же помечает её как критическую. Произошло вот что: API вернул 37°F, кто-то подписал это celsius, потому что в имени колонки так, и логика медицинского порога сравнивала с шкалой Цельсия. Профилактика — сделать так, чтобы единицу нёс тип, а не имя переменной.
Трактовка температуры как экстенсивной величины
averageTemperature имеет смысл. sumTemperatures — нет. Если в SQL-агрегации стоит SUM(temperature_c), что-то не так — скорее всего нужно AVG или, в редких случаях, проинтегрированная метрика градусо-дней. Температура — интенсивная величина; не складывайте две и не ждите осмысленного результата.
Округление в плавающей точке
(37 * 9 / 5) + 32 в JavaScript даёт 98,60000000000001, а не 98,6. Любой язык, использующий IEEE 754 doubles, ведёт себя так же. Варианты:
- Отображайте через
.toFixed(2)(или эквивалент в вашем языке) и остановитесь. - Используйте десятичную библиотеку (
decimal.js, PythonDecimal,BigDecimal) для аудит-уровня точности. - Храните как целые в деци-градусах (
370вместо37,0) и делите только при отображении.
Для UI-отображения toFixed(2) — правильный выбор. Для биллинговых или регуляторных систем, где ошибки округления накапливаются, используйте десятичные.
Отрицательный Кельвин в валидации ввода
Кельвин неотрицателен по физическому закону. Тело запроса с { "tempK": -10 } всегда невалидно. Принуждайте это на границе — JSON schema, Pydantic, Zod, CHECK-constraint, — а не глубоко внутри бизнес-логики. Единственное исключение, квантовые системы с «отрицательной абсолютной температурой», не возникает в API, с которыми вы будете интегрироваться; если возникнет — вы уже знаете, что да.
Отсутствие единиц в UI и логах
Строка лога sensor 42: 37 бесполезна через шесть месяцев. Это Цельсий? Фаренгейт? Сырой ADC-отсчёт? Всегда пишите sensor 42: 37°C или структурируйте лог как { "sensor": 42, "value": 37, "unit": "celsius" }. Дисковое пространство дёшево; ночной production-разбор — нет.
Путаница часовых поясов и температуры
Тревел-приложения выкатывают такой баг: при пересечении пользователем часового пояса код услужливо сдвигает все поля с timestamp — включая показания температуры. Температура часовых поясов не знает. Timestamp показания требует логики часового пояса; значение показания — нет. Держите их в раздельных полях, проводите через раздельные пайплайны конверсии.
Шорткаты устного счёта
Когда конвертера под рукой нет.
Цельсий в Фаренгейт (грубо): удвойте, прибавьте 30. 20°C → 70°F (на самом деле 68). 30°C → 90°F (на самом деле 86). Точность в пределах 2–3°F на диапазоне 0–40°C — а это покрывает любую температуру, которую вы испытываете вне печи.
Фаренгейт в Цельсий (грубо): отнимите 30, разделите пополам. 80°F → 25°C (на самом деле 26,7). 60°F → 15°C (на самом деле 15,6). Та же точность.
Цельсий в Кельвин: прибавьте 273 и округлите. Теряете 0,15 K, что ниже точности термометра вне физической лаборатории.
Два якоря, которые стоит запомнить: 20°C = 68°F ≈ 293 K, и 100°C = 212°F = 373,15 K. От них линейная интерполяция даёт достаточно близкое значение для любой оценки.
Быстро-и-грязные правила покрывают путешествия, кулинарные прикидки и прогнозы погоды. Для всего, что попадает в код или регуляторное досье, используйте точные формулы — или откройте наш бесплатный инструмент конвертации температуры и скопируйте точное значение.
Справочные таблицы
Бытовые температуры
| Контекст | Цельсий | Фаренгейт | Кельвин |
|---|---|---|---|
| Домашний морозильник | −18°C | 0°F | 255,15 K |
| Точка замерзания | 0°C | 32°F | 273,15 K |
| Холодильник | 4°C | 39°F | 277,15 K |
| Комнатная температура | 20°C | 68°F | 293,15 K |
| Температура тела | 37°C | 98,6°F | 310,15 K |
| Порог лихорадки | 38°C | 100,4°F | 311,15 K |
| Жаркий летний день | 35°C | 95°F | 308,15 K |
| Кипение воды | 100°C | 212°F | 373,15 K |
Кулинария и духовка
| Режим духовки | Цельсий | Фаренгейт |
|---|---|---|
| Низкий / медленное томление | 125°C | 257°F |
| Тёплая выпечка | 150°C | 302°F |
| Умеренная выпечка | 175°C | 347°F |
| Стандартная выпечка (торты) | 180°C | 356°F |
| Жарка | 190°C | 374°F |
| Сильная жарка | 200°C | 392°F |
| Высокая жарка | 220°C | 428°F |
| Пицца / корка хлеба | 250°C | 482°F |
Американские рецепты округляют 350°F до 175°C или 180°C в зависимости от книги; точное значение 176,67°C. Любой выбор сработает — домашние духовки редко держат температуру лучше ±5°C.
Научные крайности
| Явление | Кельвин | Цельсий |
|---|---|---|
| Абсолютный ноль (теоретический пол) | 0 K | −273,15°C |
| Реликтовый микроволновый фон | 2,725 K | −270,425°C |
| Жидкий гелий (кипение, 1 atm) | 4,2 K | −268,95°C |
| Сверхпроводник (переход YBCO) | 93 K | −180,15°C |
| Жидкий азот (кипение) | 77 K | −196,15°C |
| Тень глубокого космоса | ~40 K | ~−233°C |
| Сухой лёд (сублимация) | 194,65 K | −78,5°C |
| Поверхность Солнца | 5778 K | 5504,85°C |
| Ядро Солнца | 1,57×10⁷ K | 1,57×10⁷ °C* |
| Плазма токамака (цель ITER) | 1,5×10⁸ K | ~1,5×10⁸ °C* |
*При таких порядках величины смещение 273,15 K — это ошибка округления; Цельсий и Кельвин читаются одинаково.
FAQ
Какая формула перевода Цельсия в Фаренгейт?
Умножьте Цельсий на 9/5 (или 1,8), прибавьте 32: °F = °C × 9/5 + 32. Например, 25°C × 1,8 + 32 = 77°F. Множитель отражает отношение 180:100 диапазонов двух шкал от замерзания до кипения, а 32 выравнивают разные нули.
Какая формула перевода Фаренгейта в Цельсий?
Вычтите 32 из значения Фаренгейта, затем умножьте на 5/9: °C = (°F − 32) × 5/9. Для 72°F расчёт (72 − 32) × 5/9 = 40 × 5/9 ≈ 22,22°C. Сначала вычитание, потом умножение — обратный порядок даст неверный ответ.
При какой температуре Цельсий и Фаренгейт равны?
Точно при −40 градусов. Положив °C = °F в формулу, получаем °C = °C × 9/5 + 32, что решается как °C = −40. Это единственная температура, где две шкалы читают одно и то же число — полезный санитарный ориентир и для реальных морозов, и для багов направления конверсии.
Как перевести 350°F в Цельсий для выпечки?
350°F — это около 176,67°C. Европейские рецепты обычно округляют до 180°C, а многие американо-метрические таблицы используют 175°C. И то, и то сработает в домашней духовке — стабильность температуры в этом диапазоне хуже ошибки округления. Для точных значений, когда это важно, используйте наш конвертер температуры.
Сколько 100°F в Цельсии?
100°F ≈ 37,78°C. Это чуть выше нормальной температуры тела (37°C / 98,6°F) и часто помечается как начало небольшой лихорадки. Медицинские рекомендации используют 38°C / 100,4°F как истинный порог лихорадки, поэтому 100°F пограничны, но клинически ещё незначимы.
Почему абсолютный ноль −273,15°C, а не просто −273?
Потому что переопределение SI 2019 года точно зафиксировало постоянную Больцмана, делая −273,15°C точным вычисленным значением абсолютного нуля, а не округлённым приближением. До 2019 года ноль Цельсия был привязан к тройной точке воды, и 0,15 приходило из измерения. Теперь это точное значение по определению.
Когда использовать Кельвин вместо Цельсия в коде?
Всегда, когда вы умножаете, делите или возводите температуру в степень — излучение чёрного тела (T⁴), расчёты идеального газа, скорости реакций. Кельвин никогда не уходит в отрицательные, поэтому деление остаётся стабильным. Для температурных разностей Цельсий и Кельвин взаимозаменяемы (изменение на 5 градусов одинаково).
Используется ли Ранкин в 2026 году?
Да, но узко. Американские механика, HVAC и аэрокосмическая инженерия до сих пор используют Ранкин для термодинамического анализа цикла, где все остальные входы в Фаренгейте. Вне этих областей и вне США шкала фактически мертва. Если пишете софт общего назначения, поддержка Ранкина — дешёвая страховка, но редко несущая.
Как перевести температуру в SQL-запросе?
Вставьте формулу прямо или используйте GENERATED ALWAYS AS-колонку. Пример: SELECT celsius * 9.0 / 5.0 + 32.0 AS fahrenheit FROM readings. 9.0 и 5.0 (а не 9 и 5) принуждают арифметику с плавающей точкой в большинстве диалектов; целочисленное деление тихо отрежет дробь. Добавьте CHECK (celsius >= -273.15), чтобы отвергать абсурдные значения на insert.
Какой самый простой способ перевести Цельсий в Фаренгейт в уме?
Удвойте Цельсий и прибавьте 30. 22°C × 2 + 30 = 74°F (на самом деле 71,6°F). Точность в пределах 2°F на диапазоне 0–30°C, что покрывает почти все погоды и комнатные показания. Для обратного направления: вычтите 30 из Фаренгейта и разделите пополам.
Почему мой конвертер возвращает 98,599999 для 37°C?
Потому что 9/5 = 1,8 нельзя представить точно в двоичной плавающей точке, поэтому 37 × 9 / 5 + 32 выходит как 98,60000000000001, а не 98,6. Это поведение IEEE 754, не баг. Используйте toFixed(2) для отображения или переключитесь на десятичную библиотеку, если точность последних знаков важна в вашей задаче.
Можно ли хранить температуры как целые, чтобы избежать проблем плавающей точки?
Да — храните деци-Цельсии (температура × 10). 37,0°C становится 370, 22,5°C становится 225. Целочисленная математика точна, делите на 10 только на границе отображения. Этот паттерн распространён в встраиваемых системах и высоконагруженных time-series базах, где диск и CPU имеют значение.
Как обрабатывать числа без единиц в ответе API?
Никак. У каждого температурного поля должна быть явная единица — либо в имени поля (temp_celsius, temp_k), либо в соседнем поле unit. Если вы потребитель и API этого не даёт, громко документируйте допущение в коде и пишите контрактный тест, который ломается, если дефолт API меняется.
Какова температура кипения воды во всех четырёх шкалах?
100°C = 212°F = 373,15 K = 671,67°R, при стандартном атмосферном давлении (одна атмосфера, 101,325 kPa). Давление имеет значение: на высоте Денвера вода кипит около 95°C; на вершине Эвереста — ближе к 71°C. Точка кипения — величина, зависящая от давления, а не универсальная константа.
Действует ли температура на расчёты с плавающей точкой иначе, чем другие числа?
Нет — значения температуры ведут себя как любые другие числа с плавающей точкой. Практическая ловушка в том, что коэффициенты 5/9 и 9/5 в формулах конвертации вносят ошибку округления на каждом шаге. Для значений Кельвина в диапазоне 200–400 точности с лихвой. Для отрицательных Цельсиев у края представимых double-ов точность тоже остаётся приемлемой. Реальная ловушка — цепочки конверсий, накапливающие мелкие ошибки. Конвертируйте один раз и храните каноническую форму.