Комментарии 70
Добавил в избранное — перечитать до полного понимания )
+9
Автор статьи находится ровно на 1 шаг впереди вас в понимании того, о чем он писал. Если вы будете перечитывать это «до полного понимания», то вы просто заполните собственную голову тем… набором неупорядоченных фактов, который в голове у него. Суть статьи я бы изложил гораздо короче:
1. При нахождении времени часовом поясе (временной зоне, time zone) A по времени в часовом поясе B удобно пользоваться в качестве посредника универсальным временем, которое одно и то же в любой точке Земли и даже в космосе. Оно называется всемирным координированным временем (Universal Coordinated Time, UTC).
2. В Unix и многих языках программирования ряд функций возвращают и принимают в качестве аргумента время UTC не в удобном для человека виде (17:20 5 сентября 2001 года), а в виде, удобном для компьютера — в виде числа секунд, прошедших с условного начала «эпохи Unix» (полночь 1 января 1970 г.) Обычно это целое число, помещающееся в 32-битный регистр микропроцессора. Такое число называют Unix timestamp или просто Unix time.
3. UTC отсчитывается атомными часами. Иногда, чтобы привести в соответствие UTС времени, получаемому из астрономических наблюдений, в него вводят так называемые leap seconds (аналогичные leap years — високосным годам), когда последняя минута в году состоит не из 60, а из 61 секунды.
4. Для времени, получаемого из астрономических наблюдений (всемирное время, UT), раньше использовалась другая аббревиатура — GMT (Greenwich Mean Time, cреднее гринвичское время). Она является анахронизмом, совершенно не нужна программисту, и ее использование является признаком дурного тона и плохой осведомленности программиста о стандартах времени. Для тех, кто не понимает по-русски: GMT is deprecated.
Это практически всё, что нужно знать программисту. Разглагольствовать о том, когда солнце пересекает меридиан, нелепо, потому что ни автор статьи, ни 98% читающих это не смогут сказать, что такое небесный меридиан.
1. При нахождении времени часовом поясе (временной зоне, time zone) A по времени в часовом поясе B удобно пользоваться в качестве посредника универсальным временем, которое одно и то же в любой точке Земли и даже в космосе. Оно называется всемирным координированным временем (Universal Coordinated Time, UTC).
2. В Unix и многих языках программирования ряд функций возвращают и принимают в качестве аргумента время UTC не в удобном для человека виде (17:20 5 сентября 2001 года), а в виде, удобном для компьютера — в виде числа секунд, прошедших с условного начала «эпохи Unix» (полночь 1 января 1970 г.) Обычно это целое число, помещающееся в 32-битный регистр микропроцессора. Такое число называют Unix timestamp или просто Unix time.
3. UTC отсчитывается атомными часами. Иногда, чтобы привести в соответствие UTС времени, получаемому из астрономических наблюдений, в него вводят так называемые leap seconds (аналогичные leap years — високосным годам), когда последняя минута в году состоит не из 60, а из 61 секунды.
4. Для времени, получаемого из астрономических наблюдений (всемирное время, UT), раньше использовалась другая аббревиатура — GMT (Greenwich Mean Time, cреднее гринвичское время). Она является анахронизмом, совершенно не нужна программисту, и ее использование является признаком дурного тона и плохой осведомленности программиста о стандартах времени. Для тех, кто не понимает по-русски: GMT is deprecated.
Это практически всё, что нужно знать программисту. Разглагольствовать о том, когда солнце пересекает меридиан, нелепо, потому что ни автор статьи, ни 98% читающих это не смогут сказать, что такое небесный меридиан.
+30
Man, u're the Best!
Коротко и ясно.
Коротко и ясно.
+1
Мнээ, зачем, говорите, программисту знать о том, что GMT is deprecated? Чтобы прикидываться осведомленным? А високосную секунду не только 31-го декабря прибавляют, но еще и 30 июня. Плюс, все разглагольствования находятся в секции бонус, так что я и не претендую на то, что это необходимо знать программистам. Это скорее стимул пойти почитать, пускай даже для 2% интересующихся.
И мне кажется, что суть статьи от вас все-таки ускользнула: я попытался объяснить, почему удобно пользоваться UTC, а не сухой набор фактов для запоминания.
И мне кажется, что суть статьи от вас все-таки ускользнула: я попытался объяснить, почему удобно пользоваться UTC, а не сухой набор фактов для запоминания.
+9
Еще UTC это нативное время в GPS. Их можно использовать как эталоны времени.
0
Это вообще что-то странное вы написали. В GPS используется собственный отсчёт по атомным часам, несинхронизированный ни с UTC (не используются високосные секунды, поэтому GPS time забегает вперёд), ни с UT+AT (TAI) (отсчитывается с разных годов: GPS с 1980, TAI раньше, поэтому забегает вперёд ещё больше, чем GPS time). Для пользовательских приложений GPS время, естественно, переводится в UTC отдельно.
См. также leapsecond.com/java/gpsclock.htm — показывает разное текущее время.
См. также leapsecond.com/java/gpsclock.htm — показывает разное текущее время.
0
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Да, ваш бы пример, да сайтостроителям в руки. Можно в виде jquery-плагина это оформить, чтобы после загрузки страницы пробежаться по ней и все времена перевести в локальные.
А насчет усложнил тему, иногда нужно показывать даты в разных часовых поясах, в том числе и отличным от часового пояса клиента. Например, таблица с локальными временами сбора измерений, где точки измерения находятся в разных часовых поясах.
А насчет усложнил тему, иногда нужно показывать даты в разных часовых поясах, в том числе и отличным от часового пояса клиента. Например, таблица с локальными временами сбора измерений, где точки измерения находятся в разных часовых поясах.
+1
К пункту 2 ещё хорошо бы добавить, что unix time не считает високосные секунды. Т.е.:
UTC -> unix time
23:59:58 -> X-1
23:59:59 -> X
23:59:60 -> X
23:59:61 -> X
00:00:00 -> X+1
00:00:01 -> X+2
Т.е. при конверсии между поясами для целей отображения unix time как посредником можно пользоваться, для точных задач (придумывается только задача расшифровки/визуализации логов АСУТП) — нет.
И ещё, функция time() в большинстве современных систем возвращают GMT unixtime, но в общем случае это неверно. Для получения точного GMT unixtime надо осуществлять конверсию.
UTC -> unix time
23:59:58 -> X-1
23:59:59 -> X
23:59:60 -> X
23:59:61 -> X
00:00:00 -> X+1
00:00:01 -> X+2
Т.е. при конверсии между поясами для целей отображения unix time как посредником можно пользоваться, для точных задач (придумывается только задача расшифровки/визуализации логов АСУТП) — нет.
И ещё, функция time() в большинстве современных систем возвращают GMT unixtime, но в общем случае это неверно. Для получения точного GMT unixtime надо осуществлять конверсию.
+2
Вот так надо было написать. Хотя эти факты по моему просто обязан знать каждый программист.
0
Первый раз слышу такое понятие как «instant in time», привык оперировать словосочетанием «Unix time»
+1
UNIX timestamp отсчитывает не миллисекунды, а просто секунды.
+1
Да, точно, что-то я на Джавную реализацию засмотрелся, а они еще и миллисекунды считают. В unix timestamp миллисекунды дробями идут, если нужно. Спасибо.
0
В Java еще есть наносекунды.
0
Это же не для человеческого времени, а для процессов, если вы, конечно, говорите о timeunit.
0
Если человеческое — это wall-clock (или java.util.Date), то да — там наносекунд нет. Они только на уровне системного таймера для замера времени выполнения участков кода
download.oracle.com/javase/1.5.0/docs/api/java/lang/System.html#nanoTime()
download.oracle.com/javase/1.5.0/docs/api/java/lang/System.html#nanoTime()
0
Наносекунды там поддерживают на уровне спецификации, в реализации же (под Windows, например) фактически используются секунды.
-1
а в Javascript наносекунды есть? очень нужно)
0
В реализациях Javascript в браузерах время округляется по модулю 15 ms.
ejohn.org/blog/accuracy-of-javascript-time/
ejohn.org/blog/accuracy-of-javascript-time/
0
спасибо: про 61 секунду не знал. Никак не мог раньше понять, почему на 60 дата нацело не всегда делиться, теперь стало ясно
+5
Успеют ли все перейти на 64х к 38 году? У них в запасе 28 лет! К тому времени уже 1024х перейдут =)
0
А еще у некоторых время по Гринвичу выбрано просто с целью «не так как у соседей» (вспоминая про GMT +5¾), я бы пострадал ментально, пытаясь это с настенных часов пересчитать. Вяленько так поговаривают убрать эту муть с часовыми поясами и летним/зимним временем, какая разница — к шести мне на работу или к восемнадцати? Но, думаю, об этом еще и внуки порассуждают немало.
+4
НЛО прилетело и опубликовало эту надпись здесь
Ну не соглашусь, эта статья из шишек набитых родилась в основном, пока такого вот ясного понимания не было, у нас постоянно энтузиасты во всех местах где только можно переводили из пояса в пояс (причем какими-то джедайскими методами, натурально прибавляя/отнимая часы), хранили флаг летнего/зимнего времени, подгоняли, долго не могли вкупить, что это за время отображается, и опять прибавляли/отнимали часы (чисто на глазок: а, ну тут примерно разницу между местным и московским прибавить? прибавим), вели две колонки: время местное и время московское и т.д.
А имея хорошее понимание того, как обстоят дела, можно и другие системы работы со временем осваивать (в других языках, например), и не путаться (что, на мой взгляд, главное).
А имея хорошее понимание того, как обстоят дела, можно и другие системы работы со временем осваивать (в других языках, например), и не путаться (что, на мой взгляд, главное).
+1
По поводу хранения даты в БД
>Можно придумать разные варианты решения этой проблемы — хранить отдельной колонкой признак л/з, хранить моменты во времени в колонке типа NUMBER, но наименее радикальным и простым мне кажется хранение даты/времени в UTC
Мы в свое время помучались и с тех храним время в типе аналогичном long, туда пишется System.currentTimeMillis() (в Java). Пока непреодолимых проблем это не вызвало, а уже года три как минуло с момента принятия такого решения.
>Можно придумать разные варианты решения этой проблемы — хранить отдельной колонкой признак л/з, хранить моменты во времени в колонке типа NUMBER, но наименее радикальным и простым мне кажется хранение даты/времени в UTC
Мы в свое время помучались и с тех храним время в типе аналогичном long, туда пишется System.currentTimeMillis() (в Java). Пока непреодолимых проблем это не вызвало, а уже года три как минуло с момента принятия такого решения.
0
Единственный минус, который я вижу — не очень удобно в sql-запросах фильтровать по дате, ну и таблички бд в каком-нибудь навигаторе смотреть.
0
>не очень удобно в sql-запросах фильтровать по дате
в том же мускуле есть функция FROM_UNIXTIME(), с ней не так и сложно
в том же мускуле есть функция FROM_UNIXTIME(), с ней не так и сложно
+1
Не знаю как в Oracle, а в MySQL есть тип поля timestamp, который хранит дату в UTC.
0
Да и в Oracle есть такой тип, не знаю, почему автор так уверен в том, что Oracle не работает с таймзонами
CREATE TABLE TIME_TEST
(
TSTZ TIMESTAMP WITH TIME ZONE
);
CREATE TABLE TIME_TEST
(
TSTZ TIMESTAMP WITH TIME ZONE
);
0
Ну, автор вроде как наоборот, уверен :)
Более того, автор указывает на проблему, связанную с этим:
>во время перехода в течение часа каждому значению wall clock time соответствуют два момента времени (часы дважды показывают 02:01, 02:02, 02:03 и т.д, при этом это разные моменты времени). То есть, мы не можем однозначно определить по wall clock time 02:30 27.10.2002, какой это момент во времени
Более того, автор указывает на проблему, связанную с этим:
>во время перехода в течение часа каждому значению wall clock time соответствуют два момента времени (часы дважды показывают 02:01, 02:02, 02:03 и т.д, при этом это разные моменты времени). То есть, мы не можем однозначно определить по wall clock time 02:30 27.10.2002, какой это момент во времени
0
Я так понимаю, вы с ним работаете из реального приложения, и все моменты переходов на летнее/зимнее время он у вас сохраняет и загружает как положено? Речь ведь не о поддержке часовых поясов, речь о том, чтобы гарантировано сохранить/загрузить одну и ту же дату в условиях смены зимнего/летнего времени. Если это так (если вы это _проверяли_), то я готов признать свою ошибку, если вы просто хотите ткнуть носом в документацию, которую я и так видел, что ж, спасибо, что помогли как сумели.
0
Я не собирался никого никуда тыкать. Вы сказали, что оракл хранит время в чем-то вроде wall clock time. В той же документации написано, что TIMESTAMP WITH TIME ZONE хранит время в UTC и отдельно смещение в часах и минутах. Я глубоко не тестил, у меня в приложениях с этим проблем нет Оракл все делает правильно, он знает в какой таймзоне в какой момент времени происходит переход от летнего времени к зимнему и обратно. Или имелось в виду, что например мы, например через JDBC извлекаем время и теряем инфу о таймзоне и понятия не имеем, произошел ли в данный момент времени переход или нет?
0
У вас часы на компьютере автоматически переходят на зимнее-летнее время? Главное, чтобы на сервере базы данных стояла правильная тайм зона. А даты хранятся в в timestamp и не зависят от часовых поясов и переходов.
0
Еще пара важных моментов, если требуется передавать и сравнивать unix timestamp между разными машинами в разных часовых поясах:
1) на всех машинах время должно быть точное (не забываем настроить NTP)
2) на всех машинах должно быть установлено правильное локальное время и правильный часовой пояс
Это все конечно очевидно, но вот именно такие простые мелочи так легко забыть и потом долго искать грабли
1) на всех машинах время должно быть точное (не забываем настроить NTP)
2) на всех машинах должно быть установлено правильное локальное время и правильный часовой пояс
Это все конечно очевидно, но вот именно такие простые мелочи так легко забыть и потом долго искать грабли
+1
Таких мелочей еще вагон будет, если подходить к делу как ТС. Скажу свое фи — ужасная статья.
-1
Чем высказывать фи, рассказали бы про свой опыт и про свой вагон мелочей, мне очень интересно послушать.
+1
Может сначала Вы? А то статью накатали и путного ничего. Тупо сгусток мыслей, аля «кривой пересказ вики».
-1
А если бы не накатал — вы бы высказались первым?
-1
Я бы с удовольствием пообщался на данную тему, но к сожалению, данный топик не вдохновляет/цепляет меня на это. Вот была бы интересная статья — всегда пожалуйста. :)
0
Спасибо, что не прошли мимо, а нашли в себе вдохновение пнуть статью. Очевидно, вы своей цели добились, ваши комментарии помогут мне исправить все мои ошибки и впредь писать только вдохновляющие, цепляющие топики, всем остальным же помогут избежать вагона мелких, но неприятных мелочей, про которые вы так много знаете. Еще раз, огромное вам спасибо.
+1
к 2038? =)
много ли программ вы используете с 1982 года? (те же 28 лет, только назад)
много ли программ вы используете с 1982 года? (те же 28 лет, только назад)
0
время — это вообще фикция ;-)
То, что мы не помним, мы считаем будущим, то что помним — прошлым. То, что познаем — настоящим.
Это почти цитата, только не помню откуда.
Представьте себе далекое будущее и люди летают меж звезд (неважно как) и живут на разных планетах. Каким будет календарь? И будет ли «универсальное время»?
То, что мы не помним, мы считаем будущим, то что помним — прошлым. То, что познаем — настоящим.
Это почти цитата, только не помню откуда.
Представьте себе далекое будущее и люди летают меж звезд (неважно как) и живут на разных планетах. Каким будет календарь? И будет ли «универсальное время»?
+2
всё зависит от того, будет ли возможность сверхсветовой (читай — мгновенной) синхронизации времени. А так да, в рамках ОТО время относительно. Даже между двумя наблюдателями — одни на верху высокой башни, другой внизу — часы будут идти с разной скоростью. Система GPS, кстати, учитывает это эффект.
+1
Думаю, универсального времени не будет, так как если планеты движутся друг относительно друга, то время на них течет с разной скоростью. А вообще вопрос очень интересный, гораздо интереснее, чем на одной планете время синхронизировать.
0
Скорее всего, будет бортовое атомное время и теоретическое время события на Земле (или Татуине, в зависимости от того, кто первый начнёт колонизировать космос и устанавливать межзвёздные контакты), вычисляемое исходя из траектории корабля — для оценки происходящего на других кораблях.
Возможно, бортовое атомное время будет считаться в земных часах/секундах по Гринвичу, Хьюстону или Москве, а может в чём-то экзотическом, типа стартрековской «звёздной даты».
Возможно, бортовое атомное время будет считаться в земных часах/секундах по Гринвичу, Хьюстону или Москве, а может в чём-то экзотическом, типа стартрековской «звёздной даты».
0
Когда я работал с иностранными заказчиками, то для координирования времени с удовольствием пользовался временем SIT (http://ru.wikipedia.org/wiki/Интернет-время).
Поставил себе программку, которая показывает время в этом формате и не задумываешься ни о каких часовых поясах :)
Поставил себе программку, которая показывает время в этом формате и не задумываешься ни о каких часовых поясах :)
+2
В чем проблема хранить в БД время в виде unix timestamp?
С ним оперировать и проще и быстрее.
С ним оперировать и проще и быстрее.
+2
Я там писал выше, что это все-таки не так наглядно, когда в базе ковыряешься, а так никаких особых проблем нет.
0
В БД время надо хранить в столбцах встроенного типа «дата». Если, конечно, не нужны специальные применения, для которых подойдут и unixtime событий и вообще отдельный sequence для write-only событий.
0
В чем плюс от хранения даты в столбцах типа «дата»?
Хотя все конечно зависит от платформы разработки и связки БД-платформа.
В случае php+mysql конвертировать дату в строковый формат и обратно при сохранении в БД — операция накладная и не имеющая смысла.
Хотя все конечно зависит от платформы разработки и связки БД-платформа.
В случае php+mysql конвертировать дату в строковый формат и обратно при сохранении в БД — операция накладная и не имеющая смысла.
0
Автор знаком с книгами Карнеги? ;)
0
Если коротко, то UTC это типа UTF, только обеспечивает совместимость времени, а не отображения текста. Я все правильно понял? :)
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как перестать думать о часовых поясах и начать жить