Разработка для мобильных устройств на платформе 1С имеет свои специфические особенности, одной из которых является работа с региональными стандартами. Часто разработчики сталкиваются с ситуацией, когда в мобильном приложении время упорно отображается в 12-часовом формате (с суффиксами AM/PM), хотя в настройках самого Android или iOS жестко задан 24-часовой режим. Рассмотрим подробно, почему это происходит и какими способами можно добиться корректного отображения даты и времени.
Проанализируем ситуацию: мобильная платформа 1С при определении формата даты и времени опирается не на пользовательский переключатель "24-часовой формат" в настройках телефона, а на системную Локаль (Locale) — сочетание языка и региона. Например, если в системе выбран язык "English (US)", платформа автоматически применит американские стандарты, где 12-часовой цикл является основным. Даже если вы переключите тумблер в настройках Android на 24 часа, 1С может проигнорировать это значение, так как обращается к системным библиотекам за правилами конкретного региона.
Выясним причину, по которой настройки в конфигураторе (например, HH:mm:ss) могут не срабатывать. Мобильное приложение использует нативные системные диалоги для выбора даты и времени. Если свойства поля настроены не полностью, система "подсовывает" стандартное окно ввода, которое живет по правилам операционной системы, а не вашей конфигурации.
Разберем по шагам самый надежный способ управления визуализацией данных — использование свойств элементов формы. В 1С существует два важных свойства для полей ввода даты:
Для того чтобы принудительно установить 24-часовой формат, необходимо в обоих свойствах прописать строку формата. Рассмотрим пример:
Пропишем в свойствах поля ввода на форме (или в свойствах самого реквизита в объекте конфигурации) следующую строку в поле Формат и Формат редактирования:
ДФ='dd.MM.yyyy HH:mm:ss'
Использование заглавных букв HH принципиально важно, так как в синтаксисе 1С строчные hh соответствуют 12-часовому формату, а заглавные HH — 24-часовому.
Если визуальные настройки в конфигураторе игнорируются платформой, мы можем прибегнуть к программному управлению локализацией. Это заставит приложение использовать правила конкретной страны независимо от того, какие настройки стоят у пользователя в Android. Рассмотрим, как это сделать в модуле управляемого приложения.
В процедуре ПриНачалеРаботыСистемы можно добавить код для принудительной установки русского языка и соответствующего ему формата времени. Проанализируем пример кода:
Процедура ПриНачалеРаботыСистемы()
// Устанавливаем локализацию сеанса для корректного формата даты
УстановитьЛокализациюСеанса("ru_RU");
КонецПроцедуры
Метод УстановитьЛокализациюСеанса позволяет переопределить настройки, которые платформа получила от операционной системы при запуске. Это особенно полезно, если ваше приложение используется на устройствах с разными языковыми настройками, но интерфейс и ввод данных должны быть унифицированы.
В случаях, когда нам нужно вывести дату в списке или в текстовом сообщении, не полагаясь на автоматические механизмы платформы, проанализируем использование функции Формат(). Посмотрим на пример преобразования даты в строку, которая гарантированно будет выглядеть правильно:
ДатаДляВывода = Объект.ДатаСобытия;
СтрокаВремени = Формат(ДатаДляВывода, "ДФ='dd.MM.yyyy HH:mm'");
// Теперь СтрокаВремени всегда будет в 24-часовом формате
Этот метод часто применяется в мобильных приложениях для формирования заголовков страниц или строк в динамических списках, где важна четкая визуализация времени без AM/PM.
Проанализируем влияние релизов платформы. Исторически в версиях 8.3.12 и 8.3.13 наблюдались баги, связанные с некорректной передачей региональных настроек из Java-слоя Android в ядро 1С. Если вы используете старые релизы мобильной платформы, рекомендуется выполнить следующие действия:
Если системный диалог выбора даты и времени все равно отображает 12-часовую шкалу, рассмотрим альтернативный вариант интерфейсного решения. Вместо одного реквизита с типом Дата (состав даты: Дата и время), создайте два отдельных поля ввода:
Разберем преимущество такого подхода: для поля времени можно задать маску ввода, что позволит пользователю вводить цифры напрямую с клавиатуры, не вызывая системный "барабан" выбора времени, который часто и является источником проблем с форматом AM/PM.
Важный момент: При использовании маски 99:99 в поле ввода, контроль корректности введенных часов (00-23) и минут (00-59) придется возложить на программный код в событии ПриИзменении.
Подведем итог: проблема 12-часового формата в мобильной 1С чаще всего кроется в системной локали устройства. Комбинируя жесткое указание ДФ в свойствах элементов формы и программную установку локализации сеанса через УстановитьЛокализациюСеанса(), мы можем добиться предсказуемого поведения интерфейса на любых устройствах.