Как перестать думать о часовых поясах и начать жить

    В вашей системе время играет важную роль? Ваши пользователи/компоненты распределены по территории всего земного шара, или хотя бы нашей необъятной родины? Значит, вам нужны часовые пояса. Что ж, это просто. Самое сложное, что вам придется сделать — не запутаться. Об этом мы с вами и поговорим. Для начала вам нужно научиться правильно думать. Думая правильно, все остальное будет для вас либо самоочевидным, либо достаточно простым.

    Начнем с часов. Все мы привыкли определять время, глядя на часы на стене. При работе с часовыми поясами такое время называется Wall clock time. В принципе, ничего плохого в нем нет, только в разных местах земного шара в один и тот же момент времени часы показывают разное время. Если задаться целью, можно придумать алгоритм перевода wall clock time одного часового пояса в wall clock time другого. Обычно надо прибавить/отнять разницу в часах между часовыми поясами, кроме (внимание) моментов перехода на летнее/зимнее время. Вот когда начинается переход, вычисления становятся по-настоящему сложными.

    Нам же нужно что-то простое и пуленепробиваемое, как… целое число. Так появилось понятие момента во времени (instant in time, Unix time, POSIX time, time since (unix) epoch), который представляет собой число секунд (в Java — миллисекунд), прошедших с 1 января 1970 года, 00:00:00 по GMT. Момент времени одинаков по всему земному шару — если представить, что в кто-то нажал на «паузу» и течение времени остановилось, число, соответствующее моменту времени по всей Земле будет одно и то же, независимо от часового пояса. Если бы кто-то нажал на паузу через час после того, как на Гринвиче наступил новый 1970 год, момент во времени по всей Земле показывал бы 3 600,000. А сейчас, например, это уже число 1 280 720 431,859.

    Итак, момент во времени — это универсальная конвертируемая валюта временных вычислений. Он зависит только от, хм, времени, моменты можно сравнивать (соответственно, определять, какое из событий произошло раньше, а какое позже), и в этом не участвует никакая ерунда, связанная с географическим положением, часовыми поясами и переводами часов, что кардинально повышает надежность таких вычислений. Собственно, так реализована работа со временем в Java (с версии 1.1), где java.util.Date представляет собой обертку над long-моментом во времени (датам ранее 1970 соответствуют отрицательные long-и), является Comparable, а все человеческо-календарные преобразования вынесены в отдельные классы Calendar и DateFormat.

    Про преобразования. Обычному человеку мало что скажет число 1 280 720 431,859 (хотя пытливый читатель может вычислить по нему время, когда я писал эти строки), поэтому нужно уметь переводить момент во времени в wall clock time, и, соответственно, парсить обратно wall clock time в момент во времени. Вот для этих преобразований уже требуется знать часовой пояс, и эти вычисления совсем не тривиальные. Дело в том, что в разных странах/территориях/местах мало того, что разное смещение относительно GMT (время по Гринвичу), так еще и правила этих смещений исторически несколько раз менялись и продолжают меняться (вводят/отменяют летнее время, объединяют пояса — слышали про такую инициативу у нас, наверное?, или вспомним, например, мой родной город Новосибирск, который в начале девяностых перенесли из GMT+7 в GMT+6, а в начале века в нем вообще два пояса было — граница пояса проходила по реке Оби, и на разных берегах были разные пояса). Короче, чтобы не сойти с ума, вся эта историческая информация аккуратно ведется в виде базы данных Olson tz database, названной в честь основателя Arthur David Olson, хотя редактором является Paul Eggert. В этой базе данных каждому крупному населенному пункту соответствует код (Новосибирск, например, по этой базе называется Asia/Novosibirsk) и список всех его приключений по часовым поясам, начиная с 1970 года. Эта база используется во многих (всех?) Linux/Unix/BSD-системах, насчет Windows не скажу, в Java Runtime Environment (у нее, например, были какие-то апдейты, связанные исключительно с обновлением tz database), и так далее, см., в общем, Википедию. Алгоритм преобразований времени в/из этой базы мы рассматривать не будем, будем считать, что он есть у нас готовый. Он, собственно, практически везде и есть готовый.

    Итак, сформулируем правила обращения со временем для программ, работающих в нескольких часовых поясах:
    • внутри программы работать только с моментами во времени;
    • преобразование моментов во времени в wall clock time производить только во время ввода/вывода даты. Помните, что в этом преобразовании всегда (всегда!) участвует часовой пояс, поэтому нужно следить, какой именно (это не всегда видно, потому что по умолчанию берется текущий);
    • еще один случай, когда требуется wall clock time, это календарные преобразования (вычислить начало следующего дня и т.п.). Здесь тоже нужно следить, чтобы эти преобразования происходили в правильном часовом поясе;
    • при сохранении даты/времени в базу данных делать это в часовом поясе UTC.
    Последний пункт из всего вышерассмотренного не следует, поэтому разберем его отдельно. При работе с базами данных (у меня есть опыт только с Oracle и sqlite3), а именно при сохранении/чтении из БД зачем-то требуется часовой пояс. А это значит, что после сохранения/прочтения можно попортить данные. Каким образом попортить? Есть одна неприятная особенность, связанная с переходом на с летнего (+1) на зимнее время (02:00 — 03:00 27 октября 2002, например): во время перехода в течение часа каждому значению wall clock time соответствуют два момента времени (часы дважды показывают 02:01, 02:02, 02:03 и т.д, при этом это разные моменты времени). То есть, мы не можем однозначно определить по wall clock time 02:30 27.10.2002, какой это момент во времени, потому что не знаем, летнее это еще время или зимнее. Если мы получим некий момент во времени и преобразуем его в 02:30 27.10.2002, то обратное преобразование однозначно мы уже выполнить не сможем.

    Можно придумать разные варианты решения этой проблемы — хранить отдельной колонкой признак л/з, хранить моменты во времени в колонке типа NUMBER, но наименее радикальным и простым мне кажется хранение даты/времени в UTC. В часовом поясе UTC нет перехода на летнее/зимнее время, поэтому преобразования wall clock time instant in time всегда выполняются однозначно. Кроме того, что такой подход позволяет надежно хранить все моменты во времени в БД, включая переводы часов, он еще и:
    1. дисциплинирует (если вы забудете где-то в преобразованиях указать часовой пояс, то сразу увидите, что что-то не то, по крайней мере, если вы живете не в UTC);
    2. позволяет не запутаться в датах/временах, когда информация в БД поступает из разных часовых поясов — в базе время всегда в UTC;
    3. упрощает код, так как при преобразовании времени в/из БД можно не думать о часовом поясе, он всегда один и тот же.
    Напоследок пару слов о работе с часовыми поясами в python. В python для работы с датами используется класс datetime.datetime, для работы с часовыми поясами — модуль pytz, основанный на все той же Olson tz database. Напрямую моментов времени у них нет, вместо этого есть два понятия: timezone-aware datetime и naive datetime. Первое, понятно, дата-время с указанным часовым поясом, второе — наивное дата-время, в чистом виде wall clock time без уточнения, где эти wall clock висят. Хранятся datetime в виде структур «год месяц день час минута секунда микросекунда» плюс объект tzinfo для tz-aware datetime. Момент времени можно получить только через time.time(), это будет float и он будет ограничен чем-то вроде [1970 г., 2038 г.], то есть, его легко может не хватить для каких-то вычислений. То есть, (насколько я понимаю, может быть, меня поправят?) у них в datetime что-то вроде того самого алгоритма перевода напрямую из одного часового пояса в другой реализовано, без моментов времени, зато даты теоретически любые может понимать, с 1 по 9999 годы.

    Переводится naive в tz-aware datetime с помощью метода:

    tzaware_datetime = some_timezone.localize(some_naive_datetime, is_dst=True)
    (обратите внимание на второй параметр, он нужен как раз из-за неоднозначного преобразования), либо

    another_tzaware_datetime = tzaware_datetime.astimezone(another_tz)
    (перевод tz-aware даты-времени в другой часовой пояс).

    Поскольку это все реализуется через один и тот же класс datetime.datetime и вся разница в наличии свойства tzinfo, нужно быть чертовски осторожным, чтобы не перепутать, где у нас даты с часовым поясом, а где нет. Здесь Питон хуже Джавы в том смысле, что в Джаве при распечатывании хочешь-не хочешь, а нужно DateFormat создать и часовой пояс указать, в Питоне же многие операции, в т.ч. и печать, могут и для наивных дат выполняться. Понятно, что в сколь-нибудь сложном приложении желательно позаботиться, чтобы все даты были с часовым поясом, потому что если в каком-то месте приложения окажется, что его нет, то уже фиг вычислишь, а какой он там должен быть. А с поясом и сравниваться даты будут корректно, и распечатываться, и вообще. Кроме того, поскольку при сохранении в/чтении из БД сохраняется только наивная часть (год месяц день час минута секунда микросекунда), единственный толковый способ с этим работать— это иметь в базе наивное представление в UTC.

    Бонусы


    Правила человека, работающего с календарными датами. Помните, что:
    1. не в каждом году 365 дней;
    2. не в каждом дне 24 часа;
    3. к счастью, в каждом часе 60 минут;
    4. не в каждой минуте 60 секунд (может оказаться 59 и 61. 61-ая называется leap second, добавляется либо 30 июня, либо 31 декабря, в это время часы в UTC должны показывать 23:59:60. Добавление 61-ой секунды вызвано замедляющимся вращением Земли. Возможность отнять одну секунду предусмотрена для случаев, если Земля начнет вращаться быстрее, но эта возможность еще ни разу не потребовалась).
    Время GMT вычисляется не по моменту, когда солнце пересекает мередиан, а по некоторому усредненному моменту времени этого события. Реальное пересечение меридиана может отличаться от него до 16 минут из-за эллиптичности земной орбиты.

    Хотя UTC и GMT очень похожи, но все-таки немного отличаются. Если GMT определяется по среднесолнечному времени в Королевской обсерватории в Гринвиче, то UTC отмеряется атомными часами (средневзвешенное время двухсот атомных часов в семидесяти лабораториях по всему миру, синхронизируемых через спутники). Расхождение GMT и UTC не должно превышать 0,9 секунды и компенсируется как раз добавлением leap seconds.

    Ожидается, что хранение даты в 32 signed int в UNIX-системах приведет к проблеме 2038 года, когда 31 бит переполнится и последующим моментам во времени будут соответствовать отрицательные числа, что сломает все методы сравнения. Новые 64-х битные системы и программы уже используют для хранения времени 64 бита, но успеют ли такие системы полностью заменить 32-х разрядные к 2038 году?

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 70

      +9
      Добавил в избранное — перечитать до полного понимания )
        +30
        Автор статьи находится ровно на 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
          Man, u're the Best!
          Коротко и ясно.
            +9
            Мнээ, зачем, говорите, программисту знать о том, что GMT is deprecated? Чтобы прикидываться осведомленным? А високосную секунду не только 31-го декабря прибавляют, но еще и 30 июня. Плюс, все разглагольствования находятся в секции бонус, так что я и не претендую на то, что это необходимо знать программистам. Это скорее стимул пойти почитать, пускай даже для 2% интересующихся.

            И мне кажется, что суть статьи от вас все-таки ускользнула: я попытался объяснить, почему удобно пользоваться UTC, а не сухой набор фактов для запоминания.
              0
              Еще UTC это нативное время в GPS. Их можно использовать как эталоны времени.
                0
                Это вообще что-то странное вы написали. В GPS используется собственный отсчёт по атомным часам, несинхронизированный ни с UTC (не используются високосные секунды, поэтому GPS time забегает вперёд), ни с UT+AT (TAI) (отсчитывается с разных годов: GPS с 1980, TAI раньше, поэтому забегает вперёд ещё больше, чем GPS time). Для пользовательских приложений GPS время, естественно, переводится в UTC отдельно.

                См. также 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
                      +1
                      Да, ваш бы пример, да сайтостроителям в руки. Можно в виде jquery-плагина это оформить, чтобы после загрузки страницы пробежаться по ней и все времена перевести в локальные.

                      А насчет усложнил тему, иногда нужно показывать даты в разных часовых поясах, в том числе и отличным от часового пояса клиента. Например, таблица с локальными временами сбора измерений, где точки измерения находятся в разных часовых поясах.
                      • UFO just landed and posted this here
                  +2
                  К пункту 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 надо осуществлять конверсию.
                    0
                    Вы правы, спасибо за уточнение.
                    Моя идея была в том, что, на самом деле, уточнять можно до бесконечности, современная система подсчета времени, на самом-то деле, очень сложна. Но чем больше слов писать, тем больше шанс запудрить нормальному читателю мозги, и он за деревьями не увидит леса.
                    0
                    Вот так надо было написать. Хотя эти факты по моему просто обязан знать каждый программист.
                  +1
                  Первый раз слышу такое понятие как «instant in time», привык оперировать словосочетанием «Unix time»
                    0
                    Да, это оно и есть. Добавил в статью, спасибо.
                    +1
                    UNIX timestamp отсчитывает не миллисекунды, а просто секунды.
                      0
                      Да, точно, что-то я на Джавную реализацию засмотрелся, а они еще и миллисекунды считают. В 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()
                              0
                              Да, я по это и имел в виду, только думал про представляющий wall-clock Calendar и используемый в concurrency java.util.TimeUnit.
                            –1
                            Наносекунды там поддерживают на уровне спецификации, в реализации же (под Windows, например) фактически используются секунды.
                              0
                              а в Javascript наносекунды есть? очень нужно)
                        +5
                        спасибо: про 61 секунду не знал. Никак не мог раньше понять, почему на 60 дата нацело не всегда делиться, теперь стало ясно
                          +1
                          Минута в Java может содержать и 62 секунды: «The value returned is between 0 and 61», т.е. 62 различных значения — для обработки маловероятной ситуации двух leap seconds в одной минуте. Ссылаются на стандарт ISO C.
                          0
                          Успеют ли все перейти на 64х к 38 году? У них в запасе 28 лет! К тому времени уже 1024х перейдут =)
                            0
                            не перейдут. досу (от мс) уже больше 25 лет. и ничего, до сих пор живее всех живых
                              0
                              Да и unix-у с его unix time уже 40 лет. Доживет ли до 68-ми? Уверен, что да.
                              +4
                              А еще у некоторых время по Гринвичу выбрано просто с целью «не так как у соседей» (вспоминая про GMT +5¾), я бы пострадал ментально, пытаясь это с настенных часов пересчитать. Вяленько так поговаривают убрать эту муть с часовыми поясами и летним/зимним временем, какая разница — к шести мне на работу или к восемнадцати? Но, думаю, об этом еще и внуки порассуждают немало.
                              • UFO just landed and posted this here
                                  +1
                                  Ну не соглашусь, эта статья из шишек набитых родилась в основном, пока такого вот ясного понимания не было, у нас постоянно энтузиасты во всех местах где только можно переводили из пояса в пояс (причем какими-то джедайскими методами, натурально прибавляя/отнимая часы), хранили флаг летнего/зимнего времени, подгоняли, долго не могли вкупить, что это за время отображается, и опять прибавляли/отнимали часы (чисто на глазок: а, ну тут примерно разницу между местным и московским прибавить? прибавим), вели две колонки: время местное и время московское и т.д.

                                  А имея хорошее понимание того, как обстоят дела, можно и другие системы работы со временем осваивать (в других языках, например), и не путаться (что, на мой взгляд, главное).
                                  0
                                  По поводу хранения даты в БД

                                  >Можно придумать разные варианты решения этой проблемы — хранить отдельной колонкой признак л/з, хранить моменты во времени в колонке типа NUMBER, но наименее радикальным и простым мне кажется хранение даты/времени в UTC

                                  Мы в свое время помучались и с тех храним время в типе аналогичном long, туда пишется System.currentTimeMillis() (в Java). Пока непреодолимых проблем это не вызвало, а уже года три как минуло с момента принятия такого решения.
                                    0
                                    Единственный минус, который я вижу — не очень удобно в sql-запросах фильтровать по дате, ну и таблички бд в каком-нибудь навигаторе смотреть.
                                      +1
                                      >не очень удобно в sql-запросах фильтровать по дате
                                      в том же мускуле есть функция FROM_UNIXTIME(), с ней не так и сложно
                                        0
                                        Не знаю как в Oracle, а в MySQL есть тип поля timestamp, который хранит дату в UTC.
                                          0
                                          Да и в Oracle есть такой тип, не знаю, почему автор так уверен в том, что Oracle не работает с таймзонами

                                          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, какой это момент во времени
                                              0
                                              Я так понимаю, вы с ним работаете из реального приложения, и все моменты переходов на летнее/зимнее время он у вас сохраняет и загружает как положено? Речь ведь не о поддержке часовых поясов, речь о том, чтобы гарантировано сохранить/загрузить одну и ту же дату в условиях смены зимнего/летнего времени. Если это так (если вы это _проверяли_), то я готов признать свою ошибку, если вы просто хотите ткнуть носом в документацию, которую я и так видел, что ж, спасибо, что помогли как сумели.
                                                0
                                                Я не собирался никого никуда тыкать. Вы сказали, что оракл хранит время в чем-то вроде wall clock time. В той же документации написано, что TIMESTAMP WITH TIME ZONE хранит время в UTC и отдельно смещение в часах и минутах. Я глубоко не тестил, у меня в приложениях с этим проблем нет Оракл все делает правильно, он знает в какой таймзоне в какой момент времени происходит переход от летнего времени к зимнему и обратно. Или имелось в виду, что например мы, например через JDBC извлекаем время и теряем инфу о таймзоне и понятия не имеем, произошел ли в данный момент времени переход или нет?
                                                  0
                                                  Да, это и имелось в виду. Поправлю сейчас формулировку.
                                                  0
                                                  У вас часы на компьютере автоматически переходят на зимнее-летнее время? Главное, чтобы на сервере базы данных стояла правильная тайм зона. А даты хранятся в в timestamp и не зависят от часовых поясов и переходов.
                                          +1
                                          Еще пара важных моментов, если требуется передавать и сравнивать unix timestamp между разными машинами в разных часовых поясах:
                                          1) на всех машинах время должно быть точное (не забываем настроить NTP)
                                          2) на всех машинах должно быть установлено правильное локальное время и правильный часовой пояс
                                          Это все конечно очевидно, но вот именно такие простые мелочи так легко забыть и потом долго искать грабли
                                            –1
                                            Таких мелочей еще вагон будет, если подходить к делу как ТС. Скажу свое фи — ужасная статья.
                                              +1
                                              Чем высказывать фи, рассказали бы про свой опыт и про свой вагон мелочей, мне очень интересно послушать.
                                                –1
                                                Может сначала Вы? А то статью накатали и путного ничего. Тупо сгусток мыслей, аля «кривой пересказ вики».
                                                  –1
                                                  А если бы не накатал — вы бы высказались первым?
                                                    0
                                                    Я бы с удовольствием пообщался на данную тему, но к сожалению, данный топик не вдохновляет/цепляет меня на это. Вот была бы интересная статья — всегда пожалуйста. :)
                                                      +1
                                                      Спасибо, что не прошли мимо, а нашли в себе вдохновение пнуть статью. Очевидно, вы своей цели добились, ваши комментарии помогут мне исправить все мои ошибки и впредь писать только вдохновляющие, цепляющие топики, всем остальным же помогут избежать вагона мелких, но неприятных мелочей, про которые вы так много знаете. Еще раз, огромное вам спасибо.
                                            0
                                            к 2038? =)
                                            много ли программ вы используете с 1982 года? (те же 28 лет, только назад)
                                            • UFO just landed and posted this here
                                              +2
                                              время — это вообще фикция ;-)

                                              То, что мы не помним, мы считаем будущим, то что помним — прошлым. То, что познаем — настоящим.

                                              Это почти цитата, только не помню откуда.

                                              Представьте себе далекое будущее и люди летают меж звезд (неважно как) и живут на разных планетах. Каким будет календарь? И будет ли «универсальное время»?
                                                +1
                                                всё зависит от того, будет ли возможность сверхсветовой (читай — мгновенной) синхронизации времени. А так да, в рамках ОТО время относительно. Даже между двумя наблюдателями — одни на верху высокой башни, другой внизу — часы будут идти с разной скоростью. Система GPS, кстати, учитывает это эффект.
                                                  0
                                                  Ыгым…

                                                  А допустим, возможности мгновенной синхронизации нет, но точно известна скорость распространения некого сигнала? (гипотетической волны пространства из С.Снегова)
                                                  0
                                                  Думаю, универсального времени не будет, так как если планеты движутся друг относительно друга, то время на них течет с разной скоростью. А вообще вопрос очень интересный, гораздо интереснее, чем на одной планете время синхронизировать.
                                                    0
                                                    Мне то в рамках денжена (ну ролевой игры) приходится унивесальное время учитывать, т.к… возможность путешествия между двумя некими системами часто зависит от фазы «гиперканала».

                                                    Но вот только описывая: «приближается 25 декабря, Рождество...» ловлю себя на мысли, что несу полную чушь…
                                                    0
                                                    Скорее всего, будет бортовое атомное время и теоретическое время события на Земле (или Татуине, в зависимости от того, кто первый начнёт колонизировать космос и устанавливать межзвёздные контакты), вычисляемое исходя из траектории корабля — для оценки происходящего на других кораблях.

                                                    Возможно, бортовое атомное время будет считаться в земных часах/секундах по Гринвичу, Хьюстону или Москве, а может в чём-то экзотическом, типа стартрековской «звёздной даты».
                                                    +2
                                                    Когда я работал с иностранными заказчиками, то для координирования времени с удовольствием пользовался временем SIT (http://ru.wikipedia.org/wiki/Интернет-время).

                                                    Поставил себе программку, которая показывает время в этом формате и не задумываешься ни о каких часовых поясах :)
                                                      0
                                                      О, да помню была мода. Только я тогда не догнал полезности.
                                                      +2
                                                      В чем проблема хранить в БД время в виде unix timestamp?
                                                      С ним оперировать и проще и быстрее.
                                                        0
                                                        Я там писал выше, что это все-таки не так наглядно, когда в базе ковыряешься, а так никаких особых проблем нет.
                                                          0
                                                          В БД время надо хранить в столбцах встроенного типа «дата». Если, конечно, не нужны специальные применения, для которых подойдут и unixtime событий и вообще отдельный sequence для write-only событий.
                                                            0
                                                            В чем плюс от хранения даты в столбцах типа «дата»?
                                                            Хотя все конечно зависит от платформы разработки и связки БД-платформа.
                                                            В случае php+mysql конвертировать дату в строковый формат и обратно при сохранении в БД — операция накладная и не имеющая смысла.
                                                              0
                                                              В том, что можно воспользоваться готовыми функциями конвертации в нужную форму. Зависит, конечно, от используемой БД.
                                                          0
                                                          Автор знаком с книгами Карнеги? ;)
                                                            0
                                                            боюсь что нет
                                                              0
                                                              Хм, просто заголовок уж очень созвучным мне показался с «Как перестать беспокоиться и начать жить»
                                                            0
                                                            Если коротко, то UTC это типа UTF, только обеспечивает совместимость времени, а не отображения текста. Я все правильно понял? :)
                                                              0
                                                              Скорее это как эталон метра, все остальные измерения относительно него делаются. UTF решает все-таки чисто компьютерную задачу хранения текста (можно считать, что ту же задачу решает unix timestamp), а UTC решает задачу измерения времени в реальном мире.

                                                            Only users with full accounts can post comments. Log in, please.