Обработка валют и дат без скрытых ошибок в приложениях

Почему это ломается так легко

Большинство ошибок в обработке валют и дат сначала не выглядят как ошибки. Приложение вроде бы работает. Дата отображается, сумма считается, платеж проходит. А потом клиент видит продление не в тот день, финансовый отдел находит расхождение в один цент, а поддержка получает скриншоты с двух телефонов, где для одной и той же записи указаны разные значения.

Проблема обычно начинается со смысла. Одно поле может означать три очень разные вещи: точный момент времени, календарный день без часового пояса или строку для отображения, которую уже отформатировали для человека. Это разные значения. Если одна команда хранит 2026-03-04 как локальный день, а другая читает его как полночь UTC, дата может сдвинуться назад или вперед, когда дойдет до браузера или телефона.

С деньгами происходит то же самое. Цена — это не просто число. Это может быть цена за единицу, итог с налогом, округленное значение для отображения или сумма в наименьшей денежной единице. Если мобильное приложение округляет каждую позицию, а сервер — только финальный счет, итоги начинают расходиться. Один цент кажется мелочью, пока не начинаются возвраты, выгрузки в бухгалтерию или продления.

Настройки locale делают ситуацию еще хуже, потому что устройства выбирают их тихо. Один пользователь видит 1,234.56. Другой — 1.234,56. Дата вроде 03/04/2026 может означать 4 марта или 3 апреля в зависимости от устройства, браузера или языка ОС. Никто не менял код. Изменилась среда, и изменился результат.

Такие ошибки долго остаются незаметными, потому что каждый уровень по отдельности выглядит разумно. Браузер форматирует для местного пользователя. Сервер хранит timestamp. Мобильное приложение кэширует строку. Каждый шаг сам по себе кажется безобидным. Вместе они создают баги, которые всплывают поздно — обычно тогда, когда двигаются деньги или когда отчеты должны совпасть до копейки.

Именно поэтому такие проблемы переживают тестирование. Они часто появляются в конце месяца, при смене часового пояса или на устройствах с другими региональными настройками. К этому моменту баг уже не косметический. Он затрагивает счета, зарплаты, аудит и доверие клиентов.

Назовите каждое значение до того, как сохранить его

Неясные названия полей вызывают тихие ошибки. date, time, price и total выглядят безобидно, но скрывают смысл. Дайте каждому сохраненному значению такое имя, которое сразу показывает другим разработчикам, что именно там хранится.

Календарная дата — это не то же самое, что точный момент. 2026-04-12 означает день на календаре. 2026-04-12T09:00:00Z — один конкретный момент. Если сохранить день рождения, дату платежного цикла или срок оплаты как полночь в каком-то часовом поясе, на другом устройстве это может сдвинуться на предыдущий или следующий день.

С деньгами нужен такой же подход. Всегда храните сумму и код валюты вместе. 19.99 сам по себе ничего не значит, если один экран считает, что это USD, а другой — EUR. Еще лучше выбрать один сырой формат для суммы и использовать его одинаково в браузере, на сервере и в мобильном коде.

Хорошо работает простой набор правил:

• Храните точные моменты как timestamp.
• Храните значения только даты как строки только даты.
• Храните деньги как сырую сумму плюс код валюты.
• Храните отформатированный текст отдельно от исходных данных.

Строки для отображения должны оставаться на краю приложения. 1,234.50, 1 234,50 и $1,234.50 могут обозначать одну и ту же сумму, но они нужны людям, а не для хранения или расчетов. То же самое относится к датам вроде 04/05/2026. Один пользователь прочитает это как 5 апреля. Другой — как 4 мая.

Еще нужно явно указывать, какому часовому поясу или locale принадлежит значение. Команды постоянно забывают об этом. Время начала вебинара может относиться к месту проведения события. Дедлайн по зарплате — к головному офису компании. Время напоминания — к пользователю. Если это не записать, каждая команда начнет гадать, и каждое приложение будет гадать немного по-своему.

Хорошая обработка валют и дат начинается здесь: называйте значение по смыслу, а не по внешнему виду. event_starts_at_utc, invoice_due_date, amount_minor, currency_code и user_locale — скучные названия, но именно скучные названия экономят реальные деньги и реальное время поддержки.

Где браузер, сервер и mobile расходятся

Дата или цена могут выглядеть правильно на одном экране и при этом быть неверными в системе. Проблемы начинаются тогда, когда каждая платформа сама подставляет недостающие правила.

Браузеры обычно доверяют настройкам устройства пользователя. Если ноутбук настроен на французский locale и токийское время, браузер может показать 03/04/2026 как 3 апреля, а не 4 марта, и может сдвинуть timestamp на полночь на предыдущий день. Код не сломался. Он просто следовал настройкам устройства.

Серверы часто ведут себя спокойнее, но только если вы задаете им четкие правила. Многие backend-рантаймы по умолчанию используют UTC для хранения и разбора. Это помогает, пока API не отправит дату без времени вроде 2026-03-04 или timestamp без смещения. Один клиент прочитает это как местное время, другой — как UTC, и дедлайн сдвинется на часы.

У mobile есть свои проблемы. iOS и Android могут поставляться с разными данными locale, символами чисел и поведением календаря. Старый телефон может форматировать валюту с узким символом, а новый — с кодом. И то и другое может быть правильно. Если тесты сравнивают только строки, вы получаете ложные падения. Если тестов нет, пользователи получают экраны, которые не совпадают со справкой или чеками.

С деньгами спор тот же самый. Одна платформа может округлить 1.005 до 1.01 по правилу half-up. Другая — до 1.00 по банковскому округлению. Добавьте налоги, скидки или разделенные платежи, и эти маленькие различия превращаются в проблемы при сверке.

Небольшой сценарий оплаты показывает, как быстро это происходит:

• Браузер показывает заказ, оформленный в 11:30 PM по местному времени 31 марта.
• Сервер хранит 2026-04-01T03:30:00Z.
• Мобильная квитанция группирует заказы по локальному дню и помещает его в 1 апреля.
• Налоговая строка округляется по каждой позиции на mobile, а на сервере — только по финальной сумме.

Никто не видит падения. Каждый видит свою правду. Поэтому контрактам данных между платформами нужны не только имена полей. Им нужны явные правила для часового пояса, locale и округления.

Задайте один контракт для денег и времени

Большинство тихих ошибок начинается тогда, когда каждая часть приложения сама угадывает, что означает значение. Браузер трактует дату одним способом, API хранит ее другим, а mobile добавляет свои правила. Избежать этого можно, если определить один контракт и использовать его везде.

Используйте UTC для всего, что произошло в конкретный момент. Оформленный заказ, выданный возврат, зафиксированный вход в систему или полученный вебхук должны храниться как timestamp в UTC. Пользователи по-прежнему могут видеть местное время на экране, но сохраненное событие останется одним и тем же в любой стране и на любом устройстве.

Некоторые даты вообще не являются моментами. День рождения, день выставления счета, праздник или дата продления подписки должны храниться как обычная локальная дата без времени. Сохраняйте 2026-05-01 как дату, а не как полночь UTC. Если добавить время там, где его нет, пользователи в другом часовом поясе могут увидеть 30 апреля вместо 1 мая.

С деньгами нужна та же дисциплина. Храните суммы в минорных единицах, если валюта это позволяет. Сохраняйте 1999 вместе с USD, а не 19.99 как число с плавающей точкой. Float дает крошечные расхождения, а крошечные расхождения ломают итоги, налоги и проверки платежей. Держите код валюты рядом с суммой, чтобы система могла применять правильную дробную часть и правила округления.

Отправляйте locale, timezone и currency как отдельные поля. Они не взаимозаменяемы. Locale говорит приложению, как форматировать текст и числа. Timezone говорит, как показывать время. Currency говорит, какой символ и какие правила десятичных знаков использовать. Если одно поле пытается выполнять все три задачи, ошибки появляются быстро.

Форматируйте значения только на краю системы, там, где человек действительно их видит. API и база должны передавать сырые значения вроде amount_minor: 1999, currency: "USD", occurred_at_utc: "2026-05-01T14:30:00Z", local_date: "2026-05-01", locale: "en-US" и timezone: "America/New_York". А потом web-приложение или mobile-приложение превращает их в $19.99, May 1, 2026 или 10:30 AM для отображения. Одно это правило предотвращает множество тихих и дорогих ошибок.

Как внедрить это шаг за шагом

Тихие ошибки обычно начинаются еще до кода. Одна команда говорит «date», другая — «timestamp», и никто не записывает, чем они отличаются.

Начните с инвентаризации. Откройте checkout, счета, отчеты, напоминания и админ-инструменты, а затем выпишите все поля, где хранится время или деньги. Включите очевидные вещи вроде цены и даты заказа, а также то, что легко пропустить: дату начала действия ставки налога, дату окончания trial, время расчета, срок действия купона и сумму возврата.

Затем пометьте каждое поле по смыслу, а не по типу данных. Используйте «instant» для того, что происходит в один точный момент, например платеж, подтвержденный в 2026-04-12T14:03:00Z. Используйте «local date» для календарных дней вроде срока оплаты счета или дня рождения, где преобразование часового пояса изменит смысл. Используйте «local time» для времени без даты, например закрытия магазина в 18:00. Для денег храните сумму в наименьшей поддерживаемой единице, а не как float.

Для денег также нужно одно письменное правило округления. Выберите его один раз для цен, налогов и скидок, а затем используйте одинаково на вебе, в API и в mobile. Если налог округляется по каждой позиции, так должно быть везде. Если скидка округляется только после расчета общей корзины, не позволяйте одному клиенту округлять раньше. Маленькие различия быстро накапливаются.

Затем соберите один общий набор тестов. Используйте одни и те же входные данные и ожидаемые результаты для браузерного кода, серверного кода и mobile-кода. Добавьте неудобные случаи: переходы на летнее время, високосный день, валюты без десятичных знаков, валюты с тремя знаками после запятой, налоговые суммы 0.005 и даты рядом с полуночью в разных часовых поясах.

И наконец, отклоняйте плохие payload’ы как можно раньше. Если API ожидает сырую сумму в минорных единицах и ISO timestamp, отклоняйте отформатированные строки вроде 1,234.50 или 04/05/2026. Они выглядят безобидно, но locale и настройки устройства могут изменить их смысл.

Команды, которые делают это один раз, потом долго избегают потока обращений в поддержку. Исправление специально скучное, и именно поэтому оно работает.

Простой пример чекаута

Предположим, клиент в Токио покупает продукт за USD 49.00. Хорошая обработка начинается с одного правила: местоположение покупателя меняет то, как вы показываете покупку, но не саму покупку.

В браузере страница оплаты может показывать дату по токийскому времени и форматировать ее под locale пользователя. На экране это может выглядеть как 2026/05/12 10:30 и итог вроде USD 49.00. Сумма остается в USD, потому что именно это валюта выставления счета.

Сырые данные заказа должны оставаться простыми:

• amount_minor: 4900
• currency: USD
• paid_at_utc: 2026-05-12T01:30:00Z
• customer_timezone: Asia/Tokyo
• locale: ja-JP

Эта запись на сервере — источник истины. Время платежа сохраняется в UTC, поэтому все системы видят один и тот же момент. Финансы могут сверить его с платежным провайдером, поддержка — проверить точное время оплаты, и никому не нужно гадать, означает ли 05/12/2026 май или декабрь.

Счет тоже должен оставить USD как валюту выставления счета. Позже он может отформатировать сумму для отображения, но никогда не должен заменять сохраненное значение строкой вроде $49 или 49,00. Если клиент скачает счет сегодня на ноутбук, а через неделю откроет его в mobile-приложении, оба клиента должны прочитать одни и те же сырые поля и показать один и тот же итог.

Это также убирает типичную ошибку в checkout. Если браузер незаметно конвертирует USD в JPY только для отображения, а сервер списывает USD, клиент видит одно число, а платит другое. Если mobile-приложение округляет значение из float вместо использования сохраненных минорных единиц, оно может показать 48.99 или 49.01. Расхождение маленькое, а головная боль для поддержки большая.

Когда сумма хранится в минорных единицах, код валюты сохраняется один раз, а timestamp записывается в UTC, каждое устройство может форматировать данные локально и при этом соглашаться с покупкой.

Частые ошибки, из-за которых возникают тихие баги

Тихие ошибки обычно начинаются со значения, которое человеку кажется очевидным, а коду означает две разные вещи. Приложение продолжает работать. Оно просто сохраняет не то число или показывает не тот день.

03/04/2025 — классическая ловушка. Американский браузер прочитает это как 4 марта. Европейский сервис — как 3 апреля. Если вы вообще принимаете такой формат, укажите его в API и разбирайте только его. А еще лучше отправляйте 2025-04-03 для даты или полный timestamp со смещением, если важно время.

Даты снова ломаются около полуночи. Допустим, mobile-приложение отправляет 2025-04-03 00:00 как местное время, а сервер сохраняет это как UTC. Для пользователей западнее UTC это может стать предыдущим календарным днем. Поля дня рождения, даты бронирования и сроки оплаты особенно часто страдают от этого, потому что выглядят как даты, а не как моменты.

С деньгами все так же коварно. Float плохо подходит для финансовых расчетов. Округление каждой строки, а затем повторное округление финальной суммы может изменить результат по налогам или скидкам на один-два цента. Настройки locale на устройстве могут форматировать числа с неправильным десятичным разделителем или символом валюты на юридических экранах. Если копировать значения для отображения обратно в расчеты, форматированный текст смешивается с настоящими суммами.

Небольшая корзина быстро показывает проблему округления. Если три товара со скидкой стоят по 3.335, то округление каждого до 3.34 даст 10.02. Если сначала сложить их и округлить один раз, получится 10.01. Оба ответа выглядят нормально. Но только один соответствует вашему правилу.

Настройки locale помогают с отображением, но они не должны определять бизнес-правила. Телефон, настроенный на французский, может показывать 1 234,50 EUR. Это не значит, что ваш счет, экран налога или логика возврата должны сами по себе меняться. Эти экраны должны следовать рынку, валюте и политике, заданной приложением, а не тому, что предпочитает устройство.

Такие ошибки тихие именно потому, что каждый уровень считает, что поступил правильно. Пользователь замечает проблему только тогда, когда счет отличается на один цент или срок оплаты сдвигается на день назад.

Короткий чек-лист перед релизом

Большинство ошибок с деньгами и датами проходят обычное тестирование, потому что каждый экран по отдельности выглядит нормально. Ошибка появляется только тогда, когда один и тот же заказ проходит через web-приложение, API, mobile-приложение и отчеты.

Перед релизом создайте один пример заказа и не меняйте его. Используйте одного и того же клиента, одни и те же позиции, налог, скидку, валюту и timestamp везде, чтобы сравнить сырые данные с отформатированным выводом.

Проверьте этот же заказ на web, в ответе API и на mobile. Цена, налог, скидка, код валюты, сохраненный timestamp и отображаемое местное время должны указывать на одни и те же исходные значения. Проверьте пользователя, который находится далеко от часового пояса вашего сервера. Если backend работает в Европе, попробуйте пользователя в Токио или Лос-Анджелесе и посмотрите, не прыгают ли даты около полуночи.

Специально прогоняйте календарные крайние случаи. Проверьте последний день месяца, переход на летнее и зимнее время в обе стороны и високосный день. Код, который добавляет 24 часа вместо одного календарного дня, часто ломается именно здесь. Проверьте и валюты с разными правилами десятичных знаков. У JPY нет десятичных знаков, а у KWD их три. Checkout, который выглядит правильно в USD, может все равно округляться неверно в другом случае.

Экспортируйте пример заказа в отчет или CSV и сравните его с итогами на экране. Не принимайте расхождение в один цент только потому, что интерфейс выглядит «достаточно близко». Один ручной проход стоит времени, даже если у вас уже есть автоматические тесты. Поставьте один телефон на другой locale, откройте пример заказа и прочитайте каждое значение построчно.

Такая проверка скучная — именно поэтому команды ее пропускают. А потом баг первым находит финансовый отдел. Если один пример заказа остается правильным на всех клиентах и во всех отчетах, можно выпускать изменения намного увереннее.

Что делать дальше

Выберите один поток, где деньги или даты используются каждый день. Чекаут, продление подписки, счет, выплата, бронирование или окно доставки — этого достаточно. Исправить один реальный путь лучше, чем писать общие правила, которыми никто не пользуется.

Используйте этот поток, чтобы написать короткий контракт, который вся команда сможет держать открытым на одном экране. Пусть он будет простым и строгим. Точно опишите, что означает каждое значение, как оно хранится и как каждое приложение должно его показывать. Обычно в таком контракте нужны пять вещей: как хранить timestamp, является ли значение только датой или основано на времени, как хранить деньги, какое правило округления применяется и какие примеры должны проходить во всех платформах перед релизом.

Затем добавьте общие fixtures. Используйте одни и те же тестовые случаи в web, backend и mobile-коде. Если один fixture говорит, что заказ, созданный в 23:30 UTC, показывается завтра в Токио, но все еще сегодня в Нью-Йорке, каждая платформа должна доказать, что обрабатывает этот случай одинаково. То же самое сделайте для денег. Fixture с налогом, скидкой и финальной суммой часто быстро находит ошибки округления.

Для этого не нужен большой рефакторинг. Большинство команд могут начать с одного документа, небольшого файла с тестами и нескольких падающих кейсов. Часто этого достаточно, чтобы остановить привычные тихие ошибки: сдвиг на один день, неправильный символ валюты, итоги, отличающиеся на один цент, или отчеты, которые не совпадают с тем, что увидели клиенты.

Если ваша команда постоянно находит такие баги слишком поздно, поможет внешний разбор. Oleg Sotnikov из oleg.is работает как fractional CTO и часто помогает командам выстраивать такие контракты между web, backend и mobile-системами.

Хорошая обработка валют и дат — это не столько про умный код, сколько про одно общее определение. Запишите его, проверьте в каждом приложении и заставьте новую работу следовать тем же правилам.