Comments 70
Добавил в избранное — перечитать до полного понимания )
Автор статьи находится ровно на 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% читающих это не смогут сказать, что такое небесный меридиан.
Man, u're the Best!
Коротко и ясно.
Коротко и ясно.
Мнээ, зачем, говорите, программисту знать о том, что GMT is deprecated? Чтобы прикидываться осведомленным? А високосную секунду не только 31-го декабря прибавляют, но еще и 30 июня. Плюс, все разглагольствования находятся в секции бонус, так что я и не претендую на то, что это необходимо знать программистам. Это скорее стимул пойти почитать, пускай даже для 2% интересующихся.
И мне кажется, что суть статьи от вас все-таки ускользнула: я попытался объяснить, почему удобно пользоваться UTC, а не сухой набор фактов для запоминания.
И мне кажется, что суть статьи от вас все-таки ускользнула: я попытался объяснить, почему удобно пользоваться UTC, а не сухой набор фактов для запоминания.
Еще UTC это нативное время в GPS. Их можно использовать как эталоны времени.
Это вообще что-то странное вы написали. В GPS используется собственный отсчёт по атомным часам, несинхронизированный ни с UTC (не используются високосные секунды, поэтому GPS time забегает вперёд), ни с UT+AT (TAI) (отсчитывается с разных годов: GPS с 1980, TAI раньше, поэтому забегает вперёд ещё больше, чем GPS time). Для пользовательских приложений GPS время, естественно, переводится в UTC отдельно.
См. также leapsecond.com/java/gpsclock.htm — показывает разное текущее время.
См. также leapsecond.com/java/gpsclock.htm — показывает разное текущее время.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Да, ваш бы пример, да сайтостроителям в руки. Можно в виде jquery-плагина это оформить, чтобы после загрузки страницы пробежаться по ней и все времена перевести в локальные.
А насчет усложнил тему, иногда нужно показывать даты в разных часовых поясах, в том числе и отличным от часового пояса клиента. Например, таблица с локальными временами сбора измерений, где точки измерения находятся в разных часовых поясах.
А насчет усложнил тему, иногда нужно показывать даты в разных часовых поясах, в том числе и отличным от часового пояса клиента. Например, таблица с локальными временами сбора измерений, где точки измерения находятся в разных часовых поясах.
К пункту 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 надо осуществлять конверсию.
Вот так надо было написать. Хотя эти факты по моему просто обязан знать каждый программист.
Первый раз слышу такое понятие как «instant in time», привык оперировать словосочетанием «Unix time»
UNIX timestamp отсчитывает не миллисекунды, а просто секунды.
Да, точно, что-то я на Джавную реализацию засмотрелся, а они еще и миллисекунды считают. В unix timestamp миллисекунды дробями идут, если нужно. Спасибо.
В Java еще есть наносекунды.
Это же не для человеческого времени, а для процессов, если вы, конечно, говорите о timeunit.
Если человеческое — это 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()
Наносекунды там поддерживают на уровне спецификации, в реализации же (под Windows, например) фактически используются секунды.
а в Javascript наносекунды есть? очень нужно)
В реализациях Javascript в браузерах время округляется по модулю 15 ms.
ejohn.org/blog/accuracy-of-javascript-time/
ejohn.org/blog/accuracy-of-javascript-time/
спасибо: про 61 секунду не знал. Никак не мог раньше понять, почему на 60 дата нацело не всегда делиться, теперь стало ясно
Успеют ли все перейти на 64х к 38 году? У них в запасе 28 лет! К тому времени уже 1024х перейдут =)
А еще у некоторых время по Гринвичу выбрано просто с целью «не так как у соседей» (вспоминая про GMT +5¾), я бы пострадал ментально, пытаясь это с настенных часов пересчитать. Вяленько так поговаривают убрать эту муть с часовыми поясами и летним/зимним временем, какая разница — к шести мне на работу или к восемнадцати? Но, думаю, об этом еще и внуки порассуждают немало.
UFO just landed and posted this here
Ну не соглашусь, эта статья из шишек набитых родилась в основном, пока такого вот ясного понимания не было, у нас постоянно энтузиасты во всех местах где только можно переводили из пояса в пояс (причем какими-то джедайскими методами, натурально прибавляя/отнимая часы), хранили флаг летнего/зимнего времени, подгоняли, долго не могли вкупить, что это за время отображается, и опять прибавляли/отнимали часы (чисто на глазок: а, ну тут примерно разницу между местным и московским прибавить? прибавим), вели две колонки: время местное и время московское и т.д.
А имея хорошее понимание того, как обстоят дела, можно и другие системы работы со временем осваивать (в других языках, например), и не путаться (что, на мой взгляд, главное).
А имея хорошее понимание того, как обстоят дела, можно и другие системы работы со временем осваивать (в других языках, например), и не путаться (что, на мой взгляд, главное).
По поводу хранения даты в БД
>Можно придумать разные варианты решения этой проблемы — хранить отдельной колонкой признак л/з, хранить моменты во времени в колонке типа NUMBER, но наименее радикальным и простым мне кажется хранение даты/времени в UTC
Мы в свое время помучались и с тех храним время в типе аналогичном long, туда пишется System.currentTimeMillis() (в Java). Пока непреодолимых проблем это не вызвало, а уже года три как минуло с момента принятия такого решения.
>Можно придумать разные варианты решения этой проблемы — хранить отдельной колонкой признак л/з, хранить моменты во времени в колонке типа NUMBER, но наименее радикальным и простым мне кажется хранение даты/времени в UTC
Мы в свое время помучались и с тех храним время в типе аналогичном long, туда пишется System.currentTimeMillis() (в Java). Пока непреодолимых проблем это не вызвало, а уже года три как минуло с момента принятия такого решения.
Единственный минус, который я вижу — не очень удобно в sql-запросах фильтровать по дате, ну и таблички бд в каком-нибудь навигаторе смотреть.
>не очень удобно в sql-запросах фильтровать по дате
в том же мускуле есть функция FROM_UNIXTIME(), с ней не так и сложно
в том же мускуле есть функция FROM_UNIXTIME(), с ней не так и сложно
Не знаю как в Oracle, а в MySQL есть тип поля timestamp, который хранит дату в UTC.
Да и в Oracle есть такой тип, не знаю, почему автор так уверен в том, что Oracle не работает с таймзонами
CREATE TABLE TIME_TEST
(
TSTZ TIMESTAMP WITH TIME ZONE
);
CREATE TABLE TIME_TEST
(
TSTZ TIMESTAMP WITH TIME ZONE
);
Ну, автор вроде как наоборот, уверен :)
Более того, автор указывает на проблему, связанную с этим:
>во время перехода в течение часа каждому значению 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, какой это момент во времени
Я так понимаю, вы с ним работаете из реального приложения, и все моменты переходов на летнее/зимнее время он у вас сохраняет и загружает как положено? Речь ведь не о поддержке часовых поясов, речь о том, чтобы гарантировано сохранить/загрузить одну и ту же дату в условиях смены зимнего/летнего времени. Если это так (если вы это _проверяли_), то я готов признать свою ошибку, если вы просто хотите ткнуть носом в документацию, которую я и так видел, что ж, спасибо, что помогли как сумели.
Я не собирался никого никуда тыкать. Вы сказали, что оракл хранит время в чем-то вроде wall clock time. В той же документации написано, что TIMESTAMP WITH TIME ZONE хранит время в UTC и отдельно смещение в часах и минутах. Я глубоко не тестил, у меня в приложениях с этим проблем нет Оракл все делает правильно, он знает в какой таймзоне в какой момент времени происходит переход от летнего времени к зимнему и обратно. Или имелось в виду, что например мы, например через JDBC извлекаем время и теряем инфу о таймзоне и понятия не имеем, произошел ли в данный момент времени переход или нет?
У вас часы на компьютере автоматически переходят на зимнее-летнее время? Главное, чтобы на сервере базы данных стояла правильная тайм зона. А даты хранятся в в timestamp и не зависят от часовых поясов и переходов.
Еще пара важных моментов, если требуется передавать и сравнивать unix timestamp между разными машинами в разных часовых поясах:
1) на всех машинах время должно быть точное (не забываем настроить NTP)
2) на всех машинах должно быть установлено правильное локальное время и правильный часовой пояс
Это все конечно очевидно, но вот именно такие простые мелочи так легко забыть и потом долго искать грабли
1) на всех машинах время должно быть точное (не забываем настроить NTP)
2) на всех машинах должно быть установлено правильное локальное время и правильный часовой пояс
Это все конечно очевидно, но вот именно такие простые мелочи так легко забыть и потом долго искать грабли
Таких мелочей еще вагон будет, если подходить к делу как ТС. Скажу свое фи — ужасная статья.
Чем высказывать фи, рассказали бы про свой опыт и про свой вагон мелочей, мне очень интересно послушать.
Может сначала Вы? А то статью накатали и путного ничего. Тупо сгусток мыслей, аля «кривой пересказ вики».
А если бы не накатал — вы бы высказались первым?
Я бы с удовольствием пообщался на данную тему, но к сожалению, данный топик не вдохновляет/цепляет меня на это. Вот была бы интересная статья — всегда пожалуйста. :)
Спасибо, что не прошли мимо, а нашли в себе вдохновение пнуть статью. Очевидно, вы своей цели добились, ваши комментарии помогут мне исправить все мои ошибки и впредь писать только вдохновляющие, цепляющие топики, всем остальным же помогут избежать вагона мелких, но неприятных мелочей, про которые вы так много знаете. Еще раз, огромное вам спасибо.
к 2038? =)
много ли программ вы используете с 1982 года? (те же 28 лет, только назад)
много ли программ вы используете с 1982 года? (те же 28 лет, только назад)
время — это вообще фикция ;-)
То, что мы не помним, мы считаем будущим, то что помним — прошлым. То, что познаем — настоящим.
Это почти цитата, только не помню откуда.
Представьте себе далекое будущее и люди летают меж звезд (неважно как) и живут на разных планетах. Каким будет календарь? И будет ли «универсальное время»?
То, что мы не помним, мы считаем будущим, то что помним — прошлым. То, что познаем — настоящим.
Это почти цитата, только не помню откуда.
Представьте себе далекое будущее и люди летают меж звезд (неважно как) и живут на разных планетах. Каким будет календарь? И будет ли «универсальное время»?
всё зависит от того, будет ли возможность сверхсветовой (читай — мгновенной) синхронизации времени. А так да, в рамках ОТО время относительно. Даже между двумя наблюдателями — одни на верху высокой башни, другой внизу — часы будут идти с разной скоростью. Система GPS, кстати, учитывает это эффект.
Думаю, универсального времени не будет, так как если планеты движутся друг относительно друга, то время на них течет с разной скоростью. А вообще вопрос очень интересный, гораздо интереснее, чем на одной планете время синхронизировать.
Скорее всего, будет бортовое атомное время и теоретическое время события на Земле (или Татуине, в зависимости от того, кто первый начнёт колонизировать космос и устанавливать межзвёздные контакты), вычисляемое исходя из траектории корабля — для оценки происходящего на других кораблях.
Возможно, бортовое атомное время будет считаться в земных часах/секундах по Гринвичу, Хьюстону или Москве, а может в чём-то экзотическом, типа стартрековской «звёздной даты».
Возможно, бортовое атомное время будет считаться в земных часах/секундах по Гринвичу, Хьюстону или Москве, а может в чём-то экзотическом, типа стартрековской «звёздной даты».
Когда я работал с иностранными заказчиками, то для координирования времени с удовольствием пользовался временем SIT (http://ru.wikipedia.org/wiki/Интернет-время).
Поставил себе программку, которая показывает время в этом формате и не задумываешься ни о каких часовых поясах :)
Поставил себе программку, которая показывает время в этом формате и не задумываешься ни о каких часовых поясах :)
В чем проблема хранить в БД время в виде unix timestamp?
С ним оперировать и проще и быстрее.
С ним оперировать и проще и быстрее.
Я там писал выше, что это все-таки не так наглядно, когда в базе ковыряешься, а так никаких особых проблем нет.
В БД время надо хранить в столбцах встроенного типа «дата». Если, конечно, не нужны специальные применения, для которых подойдут и unixtime событий и вообще отдельный sequence для write-only событий.
Автор знаком с книгами Карнеги? ;)
Если коротко, то UTC это типа UTF, только обеспечивает совместимость времени, а не отображения текста. Я все правильно понял? :)
Sign up to leave a comment.
Как перестать думать о часовых поясах и начать жить