Что такое utc android

Проблемы времени и часовых поясов в 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 нужен дополнительный патчинг, пока вопрос находится на стадии исследования возможностей для создания юзер-френдли решения.

Источник

Как я могу получить текущее время UTC онлайн в Android?

Я использую UTC timezone и время в моем приложении для получения данных. В приложении везде, где пользователь может получить UTC времени и используется для получения данных. Я использовал этот метод, чтобы получить время UTC.

Приложение работает нормально. Но он преобразует системное время в UTC раз. Проблема в том, что иногда пользователь может изменить время на неправильное. Так что данные не поступают.

Случае выше вопрос является:

Например, текущая дата в Индии-четверг, 26 июля 2012 года, 14:27:56, часовой пояс Калькутта. Тогда время, Тихоокеанский часовой пояс, должно быть четверг, 26 июля 2012 года, 01:59:30 PDT.

Но пользователь изменил время своего устройства с 14:27:56 на 13:27:56, поэтому преобразованное время UTC будет четверг, 26 июля 2012 года, 00:59:30 PDT. На данный момент мое приложение не может получить дату из-за разницы в один час.

Я не хочу использовать классы даты, календаря для Java и не хочу использовать время устройства. Как я могу получить UTC время непосредственно, не вовлекая время устройства, дату. Есть ли для этого какой-нибудь открытый исходный код API?

7 ответов

Как я могу получить текущее время utc с помощью скрипта Lua и преобразовать его в читаемый человеком текст.

Я хочу получить текущее время UTC в миллисе. Я поискал в google и получил несколько ответов, что System.currentTimeMillis() действительно возвращает UTC времени. но это не так. Если я сделаю следующее: long t1 = System.currentTimeMillis(); long t2 = new Date().getTime(); long t3 =.

Время UTC выше SntpClient не работает, если время системы изменилось, например, вручную в течение 8 часов. Потому что он использует System.currentTimeMillis, который возвращает ложное значение.

Лучше использовать этот класс, чтобы получить правильное время UTC с сервера NTP:

И использовать его с:

Если вам нужно время UTC «now» как DateTimeString, используйте функцию:

и использовать его с:

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

Я пытаюсь получить текущее время устройства android и преобразовать его в UTC timezone, а затем мне нужно преобразовать его в Unix Timestamp . Я погуглил его, нашел несколько решений, попробовал несколько, но здесь мне ничего не помогло. Именно этим я сейчас и занимаюсь. Date date;.

Это вернет вам количество миллисекунд с 1 января 1970 года 00:00:00 UTC.

Затем просто проанализируйте его в наиболее подходящем формате, который вы хотите:

Я думаю, что вы должны реализовать клиент Sntp и получить доступ к NTP, чтобы получить сетевое время. Мой код:

Надеюсь, это вам поможет.

Используя бесплатный API в http://www.worldweatheronline.com/ , вы можете выполнить HTTP GET через java, чтобы получить текущее время в UTC (http://www.worldweatheronline.com/часовой пояс-api.aspx)

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

Вы можете использовать библиотеку Joda для управления данными даты и времени

Похожие вопросы:

Мне нужно получить текущее время UTC 0. Я читал документацию Phobos datetime и, похоже, мне нужна эта часть: Clock.currTime вернет текущее время как SysTime. Чтобы преобразовать SysTime в дату или.

a = new Date(); Sun Apr 08 2012 16:58:03 GMT+0530 (IST) Есть ли какой-нибудь способ получить текущее время UTC? Я думал о том, чтобы получить зачет по математике: b = a.getTimezoneOffset() -330.

У меня есть приложение, которое должно сравнивать время в секундах. Я хочу знать, как получить текущее время UTC в секундах. Может ли кто-нибудь опубликовать пример того, как мы можем сделать это в.

Как я могу получить текущее время utc с помощью скрипта Lua и преобразовать его в читаемый человеком текст.

Я хочу получить текущее время UTC в миллисе. Я поискал в google и получил несколько ответов, что System.currentTimeMillis() действительно возвращает UTC времени. но это не так. Если я сделаю.

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

Я пытаюсь получить текущее время устройства android и преобразовать его в UTC timezone, а затем мне нужно преобразовать его в Unix Timestamp . Я погуглил его, нашел несколько решений, попробовал.

var k=new Date(); alert(k); Это было местное время. Но мне нужно отобразить текущее время сервера UTC.

Я пытаюсь получить текущее время в UTC в приложении UWP. Это должно быть простым делом построения объекта DateTime DateTime const now< clock::now() >; и доступ к его полю UniversalTime. Однако это.

Я хочу получить текущее время конкретной страны или текущее UTC время независимо от того, в каком timezone я нахожусь или какое время я установил вручную в том же timezone или другом. Мне нужно.

Источник

Время в телефонах: что и как работает

Наверняка многие замечали проблемы с показаниями встроенных часов. Кто-то, возможно, замечал странности с отображением времени, относящегося к SMS. Особо заметно это бывает сразу после дней, когда во многих странах происходит переход на зимнее или летнее время.

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

Поясное время

Про то, что такое географические и административные «часовые пояса», или «часовые зоны», как сейчас это называется в Федеральном законе №107-ФЗ от 2011 «Об исчислении времени», я рассказывать не буду, потому что это есть в Вики.

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

Время и SMS

В отправляемом с телефона текстовом сообщении (SMS-SUBMIT) место для информации о времени вообще не предусмотрено.

Только в момент поступления сообщения в SMS-центр оно приобретает поле отметки времени — TP-Service-Centre-Time-Stamp (TP-SCTS), состоящее из 7 октетов с переставленными местами полуоктетами (GSM 03.40, TS 23.040) и представляют информацию в двоично-десятичном коде (BCD), то есть каждый полуоктет кодирует одну цифру.

Первые 6 октетов представляют год, месяц, день, час, минуты и секунды местного времени отправителя.
Седьмой октет содержит информацию о часовой зоне, и указывает отличие местного времени от UTC (GMT). Единицей измерения временного отличия служит 15 минутный интервал, а третий бит (старший в правом полуоктете) указывает алгебраический знак разницы («0» — положительная, «1» — отрицательная).
«Летнее время» должно учитываться в значении информации о часовой зоне. Например, в Великобритании значение октета часовой зоны равно 00000000b (UTC+00:00) в период зимнего времени, и 01000000b (4 х 15 минут, то есть UTC+01:00) в период летнего времени.

В структуре короткого сообщения, доставляемого на телефон получателя (SMS-DELIVER), информация о времени прибытия сообщения на SMS-центр уже присутствует, и может использоваться телефоном при отображении пользователю информации о сообщении.

Какую информацию о текущем времени сеть мобильной связи может сообщать телефону

В 1996 году в спецификациях GSM (GSM 02.42, 04.08 и др.), появились средства, позволяющие сотовым операторам доставлять на телефоны информацию о дате, времени и часовой зоне. Для этого в сигнальных сообщениях, предназначенных для управления мобильностью (Mobility Management), предусмотрены несколько информационных элементов, которые могут использоваться оператором по своему усмотрению, поскольку являются опциональными.

Прежде всего, это информационный элемент «Time Zone and Time» IE. Он содержит весь комплекс данных (год, месяц, день, час, минуты и секунды), указывающих момент, когда сеть передает сигнальное сообщение, а также значение, указывающее часовую зону, в которой расположена базовая станция.
Значения года, месяца, дня, часа, минут и секунд, как и в случае с SMS, передаются в кодировке BCD с перестановкой полуоктетов, но в отличие от метки времени SMS-центра, указывают универсальное время (UTC), а не местное!

Часть информационного элемента, указывающая часовую зону, передается в такой же кодировке, как и в случае временной отметки SMS-центра.

Вот как выглядит блок информации, переданный на телефон в конкретный момент времени:

Значение октета/его интерпретация
47 Код, означающий, что дальше идут 7 октетов IE «Time Zone and Time»
11 YEAR: 11
20 MONTH: 02
71 DAY: 17
70 HOUR: 07
71 MINUTE: 17
30 SECOND: 03
21 TIME ZONE: 12 = GMT+03:00
49 Код, означающий, что дальше идет IE «Daylight Saving Time»
01 Длина IE «Daylight Saving Time» = 1 октету
00 Значение, указывающее отсутствие сдвига из-за «летнего времени»

Поскольку в этом информационном элементе сеть передает значение «универсального времени» — UTC, для того, чтобы телефон мог отобразить местное время, он должен скорректировать UTC на значение, соответствующего сдвигу времени в часовом поясе, в котором находится телефон. В данном конкретном случае, дело происходило в Москве, еще до принятия закона «Об исчислении времени» и отмены перехода на зимнее время.

Таким образом, переданное сетью время соответствовало 10 часам 17 минутам и 3 секундам утра Московского времени 17 февраля 2011 года. Для сравнения, блок информации, переданный на телефон совсем недавно:

Значение октета/его интерпретация
47 Код, означающий, что дальше идут 7 октетов IE «Time Zone and Time»
21 YEAR: 12
40 MONTH: 04
81 DAY: 18
80 HOUR: 08
45 MINUTE: 54
44 SECOND: 44
61 TIME ZONE: 16 = GMT+04:00
49 Код, означающий, что дальше идет IE «Daylight Saving Time»
01 Длина IE «Daylight Saving Time» = 1 октету
00 Значение, указывающее отсутствие сдвига из-за «летнего времени»
Этот информация была передана в Москве в 12:54:44 18 апреля 2012 года.

Кроме информационного элемента «Time Zone and Time», спецификациями предусмотрен и отдельный 8-битовый информационный элемент, предназначенный для передачи информации только о часовой зоне («Time Zone» IE).

Информация в нем кодируется точно так же, как и значение часовой зоны в отметке SMS-центра.
Однако особого смысла передавать «Time Zone» вместе с «Time Zone and Time» не видно.

Предусмотрен и отдельный информационный элемент («Daylight Saving Time» IE), который, если он передается, указывает на значение сдвига времени, вызванного использованием «летнего времени», которое было учтено при вычислении значения поля часовой зоны.

Конкретное значение может указывать отсутствие сдвига («00b»), сдвиг на +1 час(«01b»), и сдвиг даже на +2 часа («10b»).

Согласно спецификациям GSM/3GPP информация о времени должна доставляться на мобильный телефон при первой же возможности, когда происходит регистрация телефона в сети, изменяется часовая зона, или выполняется переход на летнее или зимнее время.

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

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

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

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

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

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

Кроме того, потенциально возможны кратковременные проблемы из-за того, что программное обеспечение сетевого оборудования и SMS-центров автоматически выполнит переход на летнее/зимнее время вопреки новым российским реальностям, или было неверно настроено в момент ввода в эксплуатацию. Но такие «нюансы» обычно быстро исправляются обслуживающим персоналом.

Другие источники информации о времени и месте

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

Многие телефоны обладают функциональностью навигаторов и могут использовать информацию о времени и местоположении из систем позиционирования (GPS, ГЛОНАСС и т.п.).

Телефоны (планшетники), подключенные к сети Интернет, могут использовать дополнительную информацию о времени с использованием NTP или SNTP, а также информацию о месте «привязки» публичных IP-адресов.
Наряду с ручными настройками времени и часовой зоны такое изобилие исходной информации в отдельных случаях может порождать для телефона проблемы с выбором – какую информацию о времени и местоположении использовать.

Как телефоны используют информацию о времени

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

Естественно, что возможности ручной установки параметров даты и времени в телефонах сохраняются и в настоящее время.

При ручной настройке пользователь сам вводит текущую дату, время и местоположение (часовой пояс) и сам несет ответственность за правильность введенной информации.

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

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

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

И сейчас ситуация с автоматическим режимом настройки даты и времени выглядит существенно интереснее.
Если сеть мобильной связи GSM/UMTS, в которой зарегистрирован телефон, не передает информацию о текущей дате и времени, то телефон вроде бы должен отображать те данные, которые ввел пользователь в ручном режиме, несмотря на то, что установлен автоматический режим. Однако нельзя полностью исключать, что разработчики каких-то моделей могут воспользоваться информацией от систем позиционирования или из Интернет.

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

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

В связи с изменением часовых зон в Российской Федерации по Федеральному закону №107-ФЗ от 2011 года «Об исчислении времени», в телефонах, программное обеспечение которых разработано раньше, данные о часовых зонах многих российских городов сейчас стали неверными. В результате, если такой телефон вместо информации о часовой зоне, полученной от сети, использует значение, установленное в ручных настройках, возможно некорректное отображение времени.

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

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

Например, для Москвы можно установить не старое значение UTC+03:00, а UTC+04:00, не обращая внимания на название города (например, Баку, Ереван или Тбилиси).

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

Известны и проблемы у некоторых моделей с трактовкой времени отправки SMS. Телефон-получатель, принимает в SMS информацию о местном времени и часовой зоне, в которой находился телефон-отправитель с одной стороны, а также от сети значения UTC и часовой зоны в месте приема SMS.

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

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

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

Источник