Разница между UTC и GMT

Привет у меня есть несколько вопросов относительно часовых поясов:

  1. Можно ли зафиксировать время только в UTC?
  2. Являются ли UTC -6 и GMT -6 одинаковыми, и означает ли это, что это местное время в США?
  3. Скажем, у меня время UTC как "02-01-2018 00:03", означает ли это, что мое местное время в США - "01-01-2018 18:00"?

Я искал в Википедии и на многих похожих сайтах, но не нашел подходящего объяснения.

5 ответов

Решение

Нет разницы во времени между Всемирным координированным временем и Гринвичским средним временем 7:17. Пятница, Всемирным координированным временем (UTC) является 7:17. Пятница, Гринвичское среднее время (GMT).

Ключевое различие: UTC и GMT являются стандартами времени, которые различаются с точки зрения их происхождения и их использования.

Процитируем timeanddate.com:

Разница между GMT и UTC:

Среднее время по Гринвичу (GMT) часто взаимозаменяемое или смешанное с всемирным координированным временем (UTC). Но GMT - это часовой пояс, а UTC - это стандартное время.

Хотя на практике GMT ​​и UTC имеют одинаковое текущее время, между ними есть принципиальная разница:

  • GMT - часовой пояс, официально используемый в некоторых европейских и африканских странах. Время может отображаться как в 24-часовом формате (0–24), так и в 12-часовом формате (1–12 часов ночи / час).
  • UTC - это не часовой пояс, а стандарт времени, который является основой для гражданского времени и часовых поясов во всем мире. Это означает, что ни одна страна или территория официально не использует UTC в качестве местного времени.

Разница в том, что GMT (также официально известный как UT, что может сбивать с толку) основано на астрономических наблюдениях, а UTC - на атомных часах.

GMT - среднее время по Гринвичу, среднее солнечное время в Королевской обсерватории в Гринвиче на южном берегу в восточном Лондоне, Великобритания. Когда солнце находится в своей самой высокой точке точно над Гринвичом, это 12:00 по Гринвичу. За исключением: Земля вращается немного неравномерно, поэтому 12 часов дня определяется как среднегодовое значение, то есть среднее время, когда солнце достигает своего пика, его кульминация. В GMT никогда не может быть високосных секунд, потому что вращение Земли не скачет.

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

Примерно 100 лет GMT использовалось как основа для определения времени во всем мире. Поскольку в наши дни мир в основном основывает точное определение времени на атомных часах, стало привычным вместо этого определять время по UTC.

По вашим вопросам:

  1. Да, время может быть записано только в UTC. Хранение времени в UTC и использование UTC для передачи даты и времени обычно считается хорошей практикой.
  2. Я полагаю, что каждый штат США должен определить свое время. И я не знаю, но я предполагаю, что сегодня они (официально или на практике) определяют время как смещение от UTC, а не от GMT. Разница между ними всегда будет меньше секунды, поэтому во многих целях вам не нужно будет заботиться. Центральное стандартное время (например, Америка / Чикаго) смещено на -6, как и летнее время в горах (например, Америка / Денвер). С другой стороны, смещение -6 не обязательно подразумевает время в США. Конечно, его используют и части Канады и Мексики, а также Галапагосские острова и остров Пасхи.
  3. Я не думаю, что вы правильно указали время вашего примера, но да, 2 января 2018 года в 00:00 UTC - это тот же момент времени, что и 1 января 2018 года в 18:00 в Чикаго и других местах, которые находятся на UTC-6 в зима (то есть зима в северном полушарии).

Дальнейшее чтение: Системы времени.

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

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

Вот еще несколько практических советов с примерами кода.

Струны

Скажем, у меня время UTC как "02-01-2018 00:03", означает ли это, что мое местное время в США - "01-01-2018 18:00"?

Эта первая часть - плохой пример, в строке даты и времени отсутствует указатель ее смещения или зоны.

Если строка указывает конкретный момент, она должна указывать либо часовой пояс (Continent/Region отформатированное имя) и / или смещение от UTC в виде количества часов, минут и секунд. Если строка предназначена для представления момента в самом UTC, это означает смещение от UTC, равное нулю.

Чтобы записать эту строку со смещением, могут применяться различные соглашения. На практике лучше всего использовать часы и минуты вместе с двоеточием, например +00:00, +05:30, или же -08:00, Начальный ноль и двоеточие необязательны, но я видел, как библиотеки ломались при обнаружении таких значений, как -0800 или же -8,

зулус

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

ISO 8601

Кроме того, передовой опыт форматирования даты и времени в текстовом формате для компьютеров - это стандартные форматы ISO 8601. Для даты и времени используется формат ГГГГ-ММ-ДДЧЧ: ММ: СС ± ЧЧ: ММ: СС. T отделяет часть даты от части времени суток. Этот формат имеет такие преимущества, как, в основном, однозначность, его легко разбирать на машине, легко читать людям в разных культурах. Еще одним преимуществом сортировки по алфавиту является также хронологический. Стандарт принимает Z сокращение также.

Итак, ваш пример UTC time as "02-01-2018 00:03" лучше сформулировано как 2018-01-02T00:03Z,

java.time

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

Единственная достойная библиотека, с которой я столкнулся, это классы java.time (см. Учебное пособие), связанные с Java 8 и более поздними версиями, и его предшественник, проект Joda-Time (также свободно перенесенный с Java на.Net в проекте Noda Time).

В java.time момент представляется тремя способами. У всех есть разрешение наносекунд.

  • Instant
    Всегда в UTC. Технически, подсчет наносекунд с начала эпохи первого момента 1970 года (1970-01-01T00:00:00Z).
  • OffsetDateTime
    Дата с указанием времени суток в контексте определенного количества часов, минут и секунд до или после UTC.
  • ZonedDateTime
    Дата с временем суток в контексте определенного часового пояса.

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

Какие изменения? Изменения продиктованы прихотями или мудростью их политиков. Политики всего мира демонстрируют склонность к изменению смещения, используемого часовыми поясами в их юрисдикции. Переход на летнее время (DST) - это один из наиболее распространенных шаблонов изменений: его график часто меняется, а решение о переходе на летнее или летнее время иногда меняется. Также происходят и другие изменения, например, в последние несколько лет Северная Корея меняет свои часы на полчаса для синхронизации с Южной Кореей, Венесуэла переводит свои часы на полчаса только для того, чтобы вернуться назад менее чем на десятилетие спустя Турция в этом году отменила запланированный переход с летнего времени на стандартное время с небольшим предупреждением, и современная Россия сделала несколько таких изменений в последние годы.

Возвращаясь к вашему примеру в пункте № 3, давайте посмотрим на некоторый код.

Скажем, у меня время UTC как "02-01-2018 00:03", означает ли это, что мое местное время в США - "01-01-2018 18:00"?

У вашего примера строки есть другая проблема. Тот 03 минута в первой части игнорируется ваша вторая часть, очевидная опечатка. Я знаю, потому что в этот день в Северной и Южной Америке не действует корректировка часовых поясов, которая занимает неполный час в 57 минут.

Ни минуты

Сначала мы анализируем вашу входную строку. Не имея какого-либо индикатора зоны или смещения, мы должны проанализировать, используя LocalDateTime, Имя LocalDateTime может вводить в заблуждение, поскольку это означает конкретную местность. Это означает любую или все населенные пункты. Для получения дополнительной информации см. Раздел В чем разница между Instant и LocalDateTime?,

String input = "2018-01-02T00:03" ;                  // Text of a date with time-of-day but without any context of time zore or offset-from-UTC. *Not* a moment, *not* a point on the timeline.
LocalDateTime ldt = LocalDateTime.parse( input ) ;   // Parsing the input as a `LocalDateTime`, a class representing a date with time but no zone/offset. Again, this does *not* represent a moment, is *not* a point on the timeline. 

универсальное глобальное время

По фактам, приведенным в Вопросе, мы знаем, что эта дата и время должны были представлять момент в UTC. Таким образом, мы можем присвоить контексту смещения от UTC ноль часов, минут и секунд для самого UTC. Мы применяем ZoneOffset постоянная UTC чтобы получить OffsetDateTime объект.

OffsetDateTime odt = ldt.atOffset( ZoneOffset.UTC );    // We are certain this text was intended to represent a moment in UTC. So correct the faulty text input by assigning the context of an offset of zero, for UTC itself.

Часовой пояс

Вопрос просит увидеть этот момент через шесть часов после часового пояса, используемого в Соединенных Штатах. Один часовой пояс с таким смещением America/Chicago,

Укажите правильное название часового пояса в формате continent/region, такие как America/Montreal, Africa/Casablanca, или же Pacific/Auckland, Никогда не используйте 2-4 буквенное сокращение, такое как CST, EST, или же IST поскольку они не являются истинными часовыми поясами, не стандартизированы и даже не уникальны (!).

ZoneId z = ZoneId.of( "America/Chicago" ) ; // Adjust from UTC to a time zone where the wall-clock time is six hours behind UTC.
ZonedDateTime zdt = odt.atZoneSameInstant( z ) ;

Смотрите этот код в прямом эфире на IdeOne.com.

odt.toString (): 2018-01-02T00: 03Z

zdt.toString (): 2018-01-01T18: 03-06: 00 [Америка / Чикаго]

В тот же момент, разное время настенных часов

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

Давайте рассмотрим пример, используя Исландию, где их часовой пояс использует смещение от UTC, равное нулю часов, минут и секунд. Итак, зона Atlantic/Reykjavik имеет время настенных часов, идентичное UTC. По крайней мере, в настоящее время их настенное время соответствует UTC; в прошлом или будущем оно может быть другим, поэтому неправильно говорить "UTC - часовой пояс Исландии". В любом случае, наш пример... скажем, кто-то в Рейкьявике, Исландия, с 3 минутами после полуночи на часах, висящих на стене, звонит кому-то в США. Этот человек из США живет в месте, где используется часовой пояс Чикагского региона. Когда человек звонит, берет трубку, он смотрит на часы, висящие на стене, и видит, что время уже после 6 вечера (18:03). Тот же самый момент, другое время настенных часов.

Кроме того, календари, висящие на их стенах, отличаются, поскольку в Исландии "завтра", а в континентальной части США - "вчера". Один и тот же момент, разные даты!


О java.time

Инфраструктура java.time встроена в Java 8 и более поздние версии. Эти классы вытесняют проблемные старые классы даты и времени, такие как java.util.Date, Calendar & SimpleDateFormat,

Проект Joda-Time, находящийся сейчас в режиме обслуживания, рекомендует перейти на классы java.time.

Чтобы узнать больше, смотрите Oracle Tutorial. И поиск переполнения стека для многих примеров и объяснений. Спецификация JSR 310.

Вы можете обмениваться объектами java.time напрямую с вашей базой данных. Используйте драйвер JDBC, соответствующий JDBC 4.2 или более поздней версии. Нет необходимости в строках, нет необходимости в java.sql.* классы.

Где взять классы java.time?

Проект ThreeTen-Extra расширяет java.time дополнительными классами. Этот проект является полигоном для возможных будущих дополнений к java.time. Вы можете найти некоторые полезные классы здесь, такие как Interval, YearWeek, YearQuarter и многое другое.

GMT - это среднее солнечное время, рассчитанное на гринвичском меридиане. https://www.rmg.co.uk/discover/explore/greenwich-mean-time-gmt

UTC основано на чрезвычайно регулярном «тиканье» атомных часов цезия. https://en.wikipedia.org/wiki/Coordinated_Universal_Time

Они не основаны на одном и том же времени и не рассчитываются одинаково. ИМХО, формулировка на https://currentmillis.com в лучшем случае вводит в заблуждение, если не просто неверно.

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

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

Но подождите, что вообще означают «более точные часы» ? Чтобы понять это, нам нужно в первую очередь понять, что такое само «время»!

Время (в его сегодняшней форме, т.е. месяцы, дни, часы, минуты и т. д.) — вещь, созданная человеком, и наше « средство измерения хода событий ». Предположим, вы планируете мероприятие по программированию в следующем месяце. Что будет в следующем месяце? Поэтому вам необходимо иметь общее и широко распространенное понимание времени (объема прохождения событий), которое мы все считаем «следующим месяцем»!

Наше сегодняшнее общее понимание «времени» является результатом соглашения/соглашения, оставленного нам нашими предками: они искали какое-то регулярно повторяющееся событие и первоначально нашли его в смене дня на ночь и в смене времен года.. (Если вы заметили, это астрономические события, т. е. вращение Земли вокруг своей оси и положение Солнца на небе. Это то, что часы GMT (часовой пояс) используют для измерения времени). Но еще есть куда совершенствоваться:

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

По сути, вы можете сказать кому-то: «Увидимся завтра», но вы не можете сказать ему: «Увидимся завтра в 7:30»! :D

Поэтому следующим [очевидным] шагом для них было сделать измерение времени более точным, и в результате они согласились (что неудивительно) разделить каждый полный день на 24 части, так называемые «часы», и они согласились разделить каждый час на 60 минут и так далее. Итак, сегодня у вас есть нечто, называемое «часами», которое позволяет вам «универсально синхронизировать свое понимание каждой точки прошлого, текущих и будущих событий с другими», поэтому вы можете с радостью планировать свое мероприятие на следующий месяц. без проблем (ну, по крайней мере, без «временных проблем»!).

Зачем тогда было нужно UTC? UTC был нужен по той же причине: это был еще один шаг на этом бесконечном пути к нашей неутолимой жажде все большей и большей точности. Как мы уже говорили выше, GMT использовало некоторые недостаточно стабильные астрономические события, чтобы сообщить нам время, то есть события, которые не настолько регулярны, как мы ожидаем положить в основу нашего современного соглашения об измерении времени.

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

Вот тут-то UTC и появляется чудесным образом. UTC измеряет «частоту вибрации атома» (*), и это оказывается гораздо более стабильным и регулярно повторяющимся событием по сравнению с такими вещами, как вращение Земли или положение Солнца на небе. Действительно, мы говорим об 1 миллиардной доле секунды в день, а не о нескольких минутах в день! Поэтому неудивительно, что UTC может поддерживать нашу синхронизацию гораздо более надежным способом.

Вот и все... по большей части! Если у вас любопытный ум, есть еще один деликатный (и важный) момент, который мы здесь не упомянули. Если задуматься, UTC великолепен с точки зрения точного измерения времени, однако он также создает (незначительную) проблему: нас действительно волнует, что такое полный день! И это независимо от того, как мы измеряем время!Независимо от того, насколько точны часы, независимо от того, насколько точно они синхронизируют нас друг с другом, нам не нравится, когда наши дни становятся темными, а ночи — яркими! (с небольшим преувеличением). Поэтому нам нужно время от времени корректировать часы UTC, и это именно то, что мы делаем, используя секунду, также известную как «дополнительная секунда», для . Из Википедии:

Дополнительная секунда — это поправка на одну секунду, которая иногда применяется ко всемирному координированному времени (UTC), чтобы учесть разницу между точным временем (международным атомным временем (TAI), измеряемым атомными часами) и неточным наблюдаемым солнечным временем (UT1). , которое меняется из-за неравномерностей и длительного замедления вращения Земли.


(*) Отказ от ответственности: я не физик и не астроном, и эти темы очень сложны, поэтому, естественно, этот ответ должен содержать некоторые неточности. Если вам нужно более глубокое и точное понимание, читайте дальше в этом ответе на Physics Stack Exchange.

Другие вопросы по тегам