oem corp time zone data что это такое

990x.top

Простой компьютерный блог для души)

Samsung Time Zone Data — что это за программа на Андроид? (com.samsung.android.timezone.data_P)

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

Samsung Time Zone Data — что это такое?

Штатное приложение для установки правильного часового пояса в зависимости от вашего местоположения.

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

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

Имя процесса — com.samsung.android.timezone.data_P.

Антивирусы в данной программе способны обнаруживать вирус UDS:DangerousObject.Multi.Generic и могут требовать удалить:

Но угрозу может увидеть только антивирус Сбербанк Онлайн, например Kaspersky, Dr.Web — молчат. Скорее всего это просто ложное срабатывание.

Возможно данная программа имеет отношение к этим настройкам:

Настройки Date and time.

Заключение

Samsung Time Zone Data — что это за программа на Андроид? (com.samsung.android.timezone.data_P) : 2 комментария

Вот Вы говорите что удалять sams. time zone data не стоит. Ну не знаю, незнаю, лично мне она нафиг не нужно,я не то что в другую страну не попаду, из-за болезни я на улице был последний раз в октябре, а сейчас сентябрь ))))
У smsung есть одна фишка, очень она меня напрягает, хотя я знаю что 90% пользователей использующих самсунги тоже не переваривают эту функцию. Да samsung красавцы в том что постоянно обновляют свои гаджеты. НО надо давать право юзерам сами решать обновлять ПО или нет. Вот у меня телефон … на сегодня он уже …… это Samsung J530F 2017. У него всего лишь 16 Гб встроеной памяти, когда покупал то стоял Android 7.1, я ставил только те приложения которыми пользовался и всегда было ещё около 4-5 гигов свободной памяти. Сейчас ПО стоит уже «девятый андрюха», из приложений стоит всего лишь Viber, Privat24, Monobank, и всё,а памяти чвободной … 1.8Гб …. это если через день захрдить и чистить кеш, если нет то 1Гб. Обновлять ПО я не хотел, 7.1 меня устраивало, но никто не спрашивает, автоматически обновило и всё, и хрен выключишь авто обнову. Выход один, удалять такие приложения как Samsung Time Zone Data.

Источник

Особенности работы со временем в различных временных зонах

Работа с различными типа данных в базах данных

MYSQL

Установим текущую зону для Москвы (в Москве с недавних пор нет перехода на летнее время, и время UTC+4):

Создадим две записи с летним и зимним временем соответственно:

Посмотрим, что показывает выборка этих дат из базы данных:

SQLite3

Рассмотрим ситуацию с sqlite3. Согласно документации в sqlite нет типа данных для сохранения времени, но есть функции для работы со временем, сохраненным в виде текста, числа с плавающей точкой и в виде целого числа. В целом эти представления принципиально ничем не отличается. Можно считать, что в sqlite текущая временная зона не используется, если вы не используете модификаторы localtime и utc. Например, вне зависимости от настроек системы, CURRENT_TIMESTAMP имеет значение в UTC.

Поэтому конвертируйте свои данные в вашей программе в utc и используйте unix epochs, чтобы не искать ошибки при парсинге строк.
Функции для отладки:

Как пользователь видит время

Если вы работаете с типом datetime и не конвертируете его, то пользователи запутаются во времени. Например, если два пользователя живут в разных временных зонах, то, видя одну и ту же строку времени без указания зоны, они будут думать о разных временах. Чтобы не повторяться, вот ссылка с примером.

С-функции по работе со временем

Во-первых, очень полезно ознакомиться с описанием работы со временем в glibc. Мы же рассмотрим несколько примеров, касающихся результатов работы нескольких функций в разных временных зонах. Оказывается, даже в документации говорится, что struct tm (далее broken-down time) обычно используется только для отображаения пользователям (из-за наглядности), т.е. в вашей программе лучше использовать другие более подходящие типы данных.
Рассмотрим несколько примеров:

Конвертирует simple time в broken-down time, выраженное относительно пользовательской зоны.

Возвращает значение для зоны UTC вне зависимости от зоны пользователя.

(синоним timelocal, но редко встречается)
Конвертирует broken-down time в simple time.
Внимание: выставляет у аргумента текущую зону.
Поле tm_zone не рассматривается как аргумент, считается, что время задано в текущей временной зоне и возвращается время в UTC.

Обратите внимение на то, что поля tm_hour и tm_isdst изменились для Лондона, это часть процесса нормализации полей структуры broken-down time.
теперь для

Работает в UTC.

теперь для

Примечание

Настройка временных зон в linux

Источник

Java и время: часть вторая

Эта статья написана в продолжение к первой части и посвящена новому Date Time API, который был введен в Java 8. Я изначально хотел оформить эту тему отдельно, поскольку она достаточно большая и серьезная. Я еще сам не в полной мере начал использовать этот API в проектах, поэтому разбираться будем вместе по ходу. В принципе в переходе на новый API нет никакой срочной необходимости, более того многие еще и не начинали проекты на Java 8, а это означает, что время на освоение еще есть.

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

История

Сравнение

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

Класс java.util.Calendar также изменяем. Хотя это особых проблем это не доставляет поскольку большинство понимает что у него есть внутреннее состояние которое меняется, да и передавать его аргументами как-то не очень принято.

Поскольку классы в старом API изменяемые, использовать их в многопоточной среде нужно с осторожностью. В частности java.util.Date можно признать «эффективно» потоко-безопасным, если вы не вызываете у него устаревшие методы.

Опасения

Об этих и других, настороживших меня кейсах расскажу подробнее уже в примерах.

Временные зоны

Начнем как обычно с временных зон. Новый класс java.time.ZoneId обозначает временную зону. Два его сабкласса java.time.ZoneRegion и java.time.ZoneOffset реализуют два типа временных зон: временную зону по географическому принципу и временную зону по простому смещению относительно UTC, UT или GMT. Правила перевода стрелок вынесены в отдельных класс java.time.zone.ZoneRules, экземпляр которого доступен через метод java.time.ZoneId#getRules.

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

Не очень понятно почему case-4, который фактически запрашивает тоже что и case-3, в результате создает java.time.ZoneRegion, а не java.time.ZoneOffset.

Для временной зоны UTC заведена специальная константа java.time.ZoneOffset#UTC, но тем не менее запрос на ZoneId.of(«UTC») в новом API выдает уже объект класса java.util.ZoneRegion, а не эту константу.

«Время — это часы» — как утверждают некоторые физики. И это фраза является ключевой для нового API, где класс java.time.Clock является краеугольным. И также как некоторые из наших часов, время для нас может быть: константным (неидущим), опаздывающим, идущим с различной степенью точности, двигающем стрелки по разному в разных часовых поясах. В общем в новом API можно использовать (либо определить самому) практически любой ход времени, в том числе и для проверки тестов.

Стандартный экземпляр java.time.Clock можно создать только фабричными статическими методами (сам класс абстрактный).

Стандартный экземпляр java.time.Clock всегда знает о временной зоне в которой его создали (хотя это бывает и ненужным).

Можно переопределить java.time.Clock и написать любую свою логику выдачи времени, например часы которые выдают случайное время на каждый запрос, почему бы и нет?

Instant

java.time.Instant — это новый java.util.Date, только неизменяемый, с наносекундной точностью и корректным названием. Внутри хранит Unix-time в виде двух полей: long с количеством секунд, и int с количеством наносекунд внутри текущей секунды.

Значение обоих полей можно запросить напрямую, а также можно попросить посчитать более привычное для старого API представление Unix-time в виде миллисекунд:

Также как и java.util.Date (при правильном его использовании), объект класса java.time.Instant ничего не знает про временную зону.

Отдельно стоит сказать про метод java.time.Instant.toString(). Если раньше java.util.Date.toString() работал с учетом текущей локали и временной зоны по умолчанию, то новый java.time.Instant.toString() всегда формирует текстовое представление во временной зоне UTC и одинаковым форматом ISO-8601 — это касается и вывода переменных в IDE при отладке:

Базовые интерфейсы

Посмотрим на базовый интерфейс java.time.temporal.TemporalAccessor. Интерфейс TemporalAccessor — это справочник для запроса отдельной частичной информации по текущей точке или метке и его реализуют все временные классы нового API.

Попросим значение Unix-time у java.time.Instant:

Получаем исключение с совершенно необъяснимым сообщением:

Немного подебажив, становится ясна причина исключения: результат теоретически может не помещаться в диапазон int (хотя в данный момент помещается). Поле INSTANT_SECONDS надо запрашивать как long. Исправим запрос, попутно запросим дополнительную мета-информацию:

Поле CLOCK_HOUR_OF_DAY не поддерживается типом Instant. Это совершенно ожидаемо, поскольку для выяснения часа дня по временной точке нам нужно указать временную зону, которой в java.time.Instant нет. Попробуем все таки запросить это значение:

Все правильно — при запросе часа дня мы получаем исключение. Прекрасно, что метод запроса не стал использовать временную зону по умолчанию (которой в новом API и нет).

Кроме запроса отдельных полей можно запрашивать значения с помощью более сложных алгоритмов-стратегий наследующих интерфейс java.time.TemporalQuery:

java.time.temporal.Temporal — интерфейс является наследником интерфейса TemporalAccessor. Вводит операции сдвига временной точки/метки вперед и назад, операцию замены части временной информации, а также операцию вычисления расстояния до другой временной точки/метки. Реализуется почти всеми «полноценными» временными классами нового API.

Пробуем сдвинуть метку на день вперед и посчитаем разницу:

Поскольку все классы наконец-то стали неизменяемыми, то результаты операций надо не забыть присвоить другой переменной, поскольку оригинальная при операции не изменяется — все аналогично java.lang.String или java.math.BigDecimal.

Попробуем изменить час дня в java.time.Instant:

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

java.time.temporal.TemporalAdjuster — интерфейс стратегии коррекции временной точки/метки, например перемещение в первый день текущего кода. Раньше приходилось для этого писать свои вспомогательные классы для работы с полями java.util.Calendar — сейчас весь код можно оформить в виде стратегии, если нужной еще нет в стандартной поставке:

Теперь можно перейти к временным классам.

LocalTime, LocalDate, LocalDateTime

java.time.LocalTime — это кортеж (час, минуты, секунды, наносекунды)
java.time.LocalDate — это кортеж (год, месяц, день месяца)
java.time.LocalDateTime — оба кортежа вместе

К этим же классам я бы отнес еще и специфические классы для хранения части информации: java.time.MonthDay, java.time.Year, java.time.YearMonth

Все эти классы объединяет то, что они содержат временные метки или их части, но временные точки на временной оси сами по себе определить не в состоянии (даже LocalDateTime) — поскольку ни в одном из них нет ни временной зоны, ни даже смещения.

Эти классы, как и все другие, поддерживают интерфейс java.lang.Comparable, но нужно понимать, что это именно сравнение временных меток, а не временных точек:

Нужно сказать, что несмотря на неизбежные параллели в использовании между java.time.LocalTime и java.sql.Time, а также между java.time.LocalDate и java.sql.Date — это совершенно различные классы. В старом API классы java.sql.Time и java.sql.Date являются наследниками java.util.Date, а это значит, что их интерпретация (получение значения часа например) зависит от временной зоны в которой объект этого класса был создан и от временной зоны в которой этот объект будет прочитан. В новом API классы java.time.LocalTime и java.time.LocalDate — это честные кортежи значений и при записи и чтении значения часа временная зона никак не участвует.

Однако временная зона необходима при создании их из временной точки, поскольку интерпретация дней-часов от нее зависит:

Исключение выбрасывается, по причине того, что временную зону взять просто неоткуда (в Instant ее нет, а зону по-умолчанию не берем). Но ее можно получить либо из часов java.time.Clock, либо передать дополнительно:

Теперь все работает, но легкость, с которой можно сделать ошибку, несколько настораживает.

В комментариях к предыдущей статье упомянули, что настоящие параноики должны еще указывать календарь при операциях с календарными значениями (что включает создание объектов всех временных классов кроме Instant). В новом API есть несколько календарей, которые названы хронологиями:

Вообще сложно представить кейс, где может потребоваться отличная от ISO-8601 хронология IsoChronology (которая практически эквивалентна грегорианскому календарю), но, если что, новый API это поддерживает.

ZonedDateTime

java.time.ZonedDateTime — аналог java.util.Calendar. Это самый мощный класс с полной информацией о временном контексте, включает временную зону, поэтому все операции со сдвигами этот класс проводит правильно.

Попробуем создать ZonedDateTime из LocalDateTime:

Сразу же получаем по рукам за то, что в операции (в LocalDateTime) нет временной зоны, а использовать временную зону по-умолчанию новое API опять отказывается (это очень хорошо).

Посмотрим, насколько ZonedDateTime строг по отношению к некорректно указанным датам. В java.util.Calendar есть переключатель lenient, который можно настроить как на «строгий», так и на «мягкий» режим. В новом API такого переключателя нет.

29-е февраля не в високосном году не пройдет:

60-ю секунду указать нельзя:

Но указание метки в момент перевода стрелок на летнее время успешно проходит, а результат отличается от ожидаемого. В строгом режиме java.util.Calendar такое не пропускал (см. предыдущую статью).

Про операции в ZonedDateTime я ничего писать не буду — можно посмотреть документацию.

OffsetTime, OffsetDateTime

java.time.OffsetTime — это LocalTime + ZoneOffset
java.time.OffsetDateTime — это LocalDateTime + ZoneOffset

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

Эти классы можно использовать, если по ситуации известно только текущее смещение пользователя (например через JavaScript). Полностью корректные операции сдвигов они не позволяют сделать, поэтому лучше использовать ZonedDateTime — если есть способ выяснить полноценную временную зону пользователя. С другой стороны, между двумя экземплярами OffsetDateTime всегда можно успешно и правильно посчитать разницу в секундах.

Модификации времени

Из всех классов нового API временную точку на временной оси однозначно определяют только три: java.time.Instant, java.time.ZonedDateTime и java.time.OffsetTime.

Операции сдвига и модификации времени в общем случае выполняются корректно только в java.time.ZonedDateTime, поскольку только он один знает про временные зоны.

Выполним пример с расчетом прошедших часов в день перевода стрелок на зимнее время:

Кейсы case#1 и case#2 выполняются на полноценном классе ZonedDateTime и выдают правильный результат, поскольку в этот день стрелки переводили назад в итоге получается 25 часов.

Кейс case#3 показывает, что OffsetDateTime полноценно сохраняет информацию о точке на временной оси, но кейс case#4 показывает, что с потерей временной зоны этот класс производит вычисления уже по другому.

То же с кейсами case#5 и case#6 — несмотря на то, что Instant полноценно определяет точку на временной оси, расчеты он производит без временной зоны.

Кейсы case#7 и case#8 — показывают, что LocalDateTime не может ни полноценно отразить временную точку, ни произвести расчеты без временной зоны.

Я ни в коем случае не хочу сказать, что эти примеры показывают ошибки в новом API (если кто-то так подумал). Все эффекты ожидаемы и объяснимы. Напрягает другое — насколько такое поведение будет осознано армией Java-разработчиков. В старом API такие потенциальные проблемы были невозможны, поскольку всеми расчетами занимался только один класс java.util.Calendar, а единственное, что в нем можно было сделать неправильно — забыть явно указать временную зону.

Возможно стоило запретить большинство операций со временем во всех классах кроме ZonedDateTime, поскольку только он один в курсе переводов стрелок. Возможно стоило запретить расчет Duration с использованием LocalDateTime, поскольку без временной зоны он не определяет временную точку. Я не готов сейчас как-то серьезно дискутировать на тему возможности или невозможности таких решений, но ощущение опасности от нового API у меня есть.

Period, Duration

В новом API есть два класса для определения длительности.

java.time.Period — описание календарной длительности (периода) в виде кортежа (год, месяц, день).

java.time.Duration — описание точной длительности в виде целого количества секунд и долей текущей секунды в виде наносекунд.

Разницу между двумя можно показать в примере с днем перевода стрелок на зимнее время. Из-за перевода стрелок назад этот календарный день состоит из 25 часов.

Источник

Проблемы времени и часовых поясов в Android и пути их решения

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

В Android существует две проблемы со временем: это его непредсказуемая синхронизация и необходимость в актуализации данных о часовых поясах даже в самой свежей версии ОС.

Предыстория: Android является мобильной ОС, базирующейся на ядре Linux, он спокойно подключается к интернету и, конечно же, можно предположить, что синхронизация времени осуществляется с помощью NTP, однако, это не так. Исторически сложилось, что Android был предназначен для использования исключительно в мобильных телефонах (вспомните версию 1.6). При этом только к 3 мажорной версии он обзавёлся интерфейсом для планшетов и начали́сь другие подвижки к унификации интерфейса и начинки ОС. Однако даже версии 4.4 и Android L получают сигналы точного времени теми же методами, что их получала Nokia 3310 и другие, более ранние GSM/3GPP телефоны, т. е. от вышек сотовой связи при регистрации в сети (при подключении к вышке). При этом планшеты или другие устройства без модуля связи, в принципе не имеют возможности синхронизировать время автоматически.

К великому сожалению, чтобы научить Android синхронизировать время полностью автоматически с помощью NTP нам понадобиться root доступ ибо API для точной установки времени в Android ныне отсутствует.

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

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

На скриншотах видно, что разница с точным временем оказалась достаточно маленькой, однако, бывают разные ситуации, у некоторых время на устройстве может даже плавать туда-сюда поскольку оператор не удосужился навести порядок у себя на БС.

Убедившись, что всё работает, настроим автоматическую синхронизацию в программе ClockSync. Для повышения точности я рекомендую включить опции «Режим высокой точности» и «Только через WI-FI». Если с первой опцией всё понятно из описания в программе (см. скриншот ниже), то вторую опцию я рекомендую включить в первую очередь не из соображений экономии мобильного трафика, а из-за того, что мобильный интернет не способен гарантировать хоть сколько-нибудь стабильные задержки.

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

В связи с масштабными изменениями часовых поясов в РФ осенью этого года необходимо уже сейчас задуматься об актуализации информации о них на всех устройствах и если с поддерживаемыми настольными ОС проблем не возникает, то в Android даже самая свежая версия ОС содержит устаревшие данные. Для того чтобы в этом убедиться устанавливаем TimeZone Fixer и наблюдаем неприглядную картину.

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

Только поэтому я и внёс этот кусочек в статью, он хоть и не имеет непосредственного отношения к проблеме, но это действительно хороший пример заботы о пользователях. В то же время предупреждение насчёт версий 4.3+ вызвано лишь малым количеством отзывов о программе для устройств с новыми версиями ОС, поэтому, пожалуйста, после использования обязательно напишите о́тзыв об этом приложении.

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

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

UPD: Эта инструкция полностью решает проблему часовых поясов только для версий младше 4.4. С версии 4.4 нужен дополнительный патчинг, пока вопрос находится на стадии исследования возможностей для создания юзер-френдли решения.

Источник