Как оформлять даты в интерфейсах, графиках и отчётах

Дата в цифровом продукте должна быстро отвечать на три вопроса: какой это день, к какому периоду он относится и можно ли сравнивать его с другими значениями. Для этого выбирайте формат по контексту, отделяйте дату от времени, учитывайте локаль и сохраняйте единообразие. Ниже разберём правила для интерфейсов, графиков и аналитических отчётов.

Дата актуальности статьи: 22 июля 2026 г.

Универсального формата даты не существует. В поле выбора важна однозначность, в списке заказов — скорость сканирования, на графике — компактность, а в выгружаемом отчёте — точность и машинная обработка. Один и тот же продукт может использовать несколько представлений даты, если правила заранее определены и пользователь понимает их без дополнительных пояснений.

В пользовательском интерфейсе дата должна соответствовать ожиданиям аудитории и помещаться в отведённую область. Для русскоязычного продукта естественно писать месяц словом в важных местах: «22 июля 2026 г.». Такая запись читается быстрее и снижает риск перепутать день и месяц. В компактных таблицах допустим цифровой формат, но его нужно использовать одинаково во всех экранах.

Если дата вводится вручную, подсказывайте допустимый формат прямо в поле или используйте календарь. Маска «ДД.ММ.ГГГГ» полезна для локального сервиса, а последовательность «ГГГГ-ММ-ДД» — для технических систем и международного обмена. Не заставляйте пользователя запоминать формат: пример должен быть виден до ввода.

В фильтрах периода лучше показывать начало и конец интервала явно: «С 1 по 22 июля 2026 года». Для короткого периода можно сократить повторяющиеся данные: «1–22 июля 2026». Если границы относятся к разным месяцам или годам, повторяйте их полностью: «28 июня — 3 июля 2026». Не используйте тире между датами без пробелов и не смешивайте дефис, короткое и длинное тире.

В кнопке действия полезнее оставить смысл, а не техническую дату. Например, «Оплатить до 22 июля» понятнее, чем «Оплатить до 22.07.2026», если год очевиден из контекста. Для юридически или финансово значимого срока показывайте полную дату и, при необходимости, время с указанием часового пояса.

На графике дата является частью шкалы, поэтому её задача — помогать сравнивать точки, а не повторять подробности в каждой подписи. Выбирайте уровень детализации по диапазону: для дня показывайте часы, для нескольких недель — дни, для года — месяцы или кварталы. Подписи должны оставаться читаемыми даже при уменьшении ширины графика.

Пример для недельного графика: на оси можно оставить подписи «15 июл.», «17 июл.», «19 июл.», «21 июл.», а в подсказке показывать полное значение «21 июля 2026, 14:30». Для годового отчёта уместны подписи «I кв.», «II кв.», «III кв.», «IV кв.» или названия месяцев. Главное — сообщить пользователю, что именно измеряет точка: день, неделю, месяц или конец периода.

В аналитическом отчёте дата должна обеспечивать проверяемость расчёта. Указывайте период анализа, дату формирования документа и, если данные обновляются автоматически, время последнего обновления. Формулировка «Данные за июнь 2026 года, обновлено 22 июля 2026 года» информативнее, чем одна дата в заголовке.

В таблицах заранее определите, что означает дата: момент события, дата регистрации, начало интервала или его окончание. Например, показатель «Продажи за 22 июля» относится ко всему дню, а «Остаток на 22 июля» обычно воспринимается как значение на определённый момент. Если это важно для интерпретации, добавьте пояснение в заголовок столбца или примечание.

В русском тексте названия месяцев пишутся со строчной буквы: «22 июля», «5 сентября». Сокращение «г.» добавляйте там, где год может быть воспринят как часть другого обозначения или где требуется официальный стиль. В обычном интерфейсе достаточно «22 июля 2026», если контекст однозначен.

Между числом и названием месяца нужен пробел, а между числом и сокращением «г.» — также пробел. В макете полезно применять неразрывный пробел, чтобы число не отделялось от месяца или года при переносе строки. Для диапазонов используйте длинное тире: «10–15 июля», а не дефис с пробелами и не два коротких дефиса.

Дата и время должны образовывать единую логическую пару, но не перегружать экран. Для события в пределах суток используйте «22 июля, 14:30». Для отчётов и журналов добавляйте год: «22 июля 2026, 14:30». Если пользователи находятся в разных часовых поясах, явно укажите зону или объясните, в какой зоне отображается время.

Относительные обозначения вроде «сегодня в 14:30» удобны в уведомлениях, но не подходят для архивов, документов и экспортов: их смысл меняется со временем. Оптимальный вариант — сочетать относительную подпись с точной датой в подсказке, деталях записи или журнале изменений.

Формат даты должен учитывать язык интерфейса, регион и настройки пользователя. Запись 03.04.2026 может означать 3 апреля или 4 марта, поэтому в международных продуктах предпочтительнее название месяца или формат с годом в начале. Локализация касается не только текста: меняются порядок компонентов, разделители, календарь и правила отображения времени.

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

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

Для важных пользовательских событий обычно подходит запись «22 июля 2026 г.» или «22 июля 2026». Она однозначна и хорошо читается. В плотных таблицах можно использовать «22.07.2026», если такой формат закреплён во всём продукте и не смешивается с международной записью.

Год нужен, если пользователь может сравнивать разные годы, просматривает архив, работает с документом или видит дату вне очевидного контекста. В ленте текущих событий год иногда можно скрыть, но точное значение должно оставаться доступным в деталях, подсказке или полном формате.

Для одного месяца используйте сокращённую запись «1–22 июля 2026 г.». Если месяцы различаются, пишите «28 июня — 3 июля 2026 г.», а при разных годах повторяйте год у каждой границы. Длинное тире визуально отделяет границы периода от дефиса внутри технических значений.

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

Для технического обмена используйте однозначное представление с годом в начале, например «2026-07-22». Для даты и времени храните полное значение с часами, минутами и, когда это необходимо, часовым поясом. Пользовательское отображение можно локализовать отдельно от исходного технического значения.

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

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

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