1. PHP / Говнокод #17952

    +172

    1. 1
    2. 2
    $lastBuildDate=date(DATE_FORMAT_RFC822);
    $lastBuildDated = str_replace ( '+0400' , '+0300' , $lastBuildDate );

    Шах и мат серверным настройкам timezone

    Запостил: talam0nal, 07 Апреля 2015

    Комментарии (31) RSS

    • Таймзона отказывалась корректно работать после прошлогодних флуктуаций с зимне-летним временем. Патч пришёл позже. швабрашвабр/post/239423/
      Ответить
      • Для пыха даже вышло расширение timezonedb, потому что он не использует системную таблицу и без переконпеляции в нём часовые пояса не обновить.

        А для Мистера Мускула табличку поясов нужно генерировать самому с помощью штатной утилиты.

        И даже после всего этого может оказаться, что какая-нибудь гадкая программа на сервере статически слинкована с устаревшей библиотекой ICU, поэтому без костылей никак...

        «Штатные» функции преобразования времени — зло. Даёшь велосипеды!
        Ответить
    • Давно пора все даты хранить в UTC. А на клиенте добавлять
      new Date().getTimezoneOffset()
      Ответить
      • Хрена лысого. На клиенте может быть плюс-минус несколько часов. Иногда спасал фарш в виде передачи дат строками, с последующим парсингом на клиенте при известной таймзоне сервера.
        Ответить
        • Ну и зачем так делать? Если у клиент "неправильное" время - может он так и хотел? Зачем пытаться угадать то, что в действительности нельзя угадать, вместо того, чтобы сделать правильно и оставить клиенту право выбора?
          Ответить
          • Для синхронизации времени между клиентом и сервером. И для генерации на клиенте: "это было 5 минут назад".
            Ответить
            • И зачем для этого переводить время в клиентское вообще?
              Ответить
              • Потому что данные хранятся на сервере. Клиент получает пачку данных с местным временем сервера. Если использовать UTC, то на клиенте может получиться "это будет 5 минут спустя".
                Ответить
                • Если у клиента правильное UTC, сервер хранит в UTC и отправляет в UTC - всё будет заебись в любом случае. Локальный пояс может быть совершенно любым, какой ему больше нравится.

                  Если у клиента неправильное UTC - ССЗБ, пусть настраивает. Можно даже ему об этом намекнуть в каком-нибудь всплывающем сообщении.
                  Ответить
                  • Здесь не всё так однозначно. Клиент, как правило, считает, что это приложение глючит.
                    Ответить
                  • У клиента? Правильное UTC? Многие клиенты, уверен, такого слова то не знают!

                    -- У вас программа не работает!
                    -- Что не работает?
                    -- Не знаю, всё не работает!
                    -- Да что конкретно то?
                    -- Не знаю. Ничего. Пока все работает. Но вы все сломали!!!!!!

                    Реальный диалог, между прочим)
                    Ответить
                  • Я вспомнил, как на одном сайте кулхацкер жаловался, что не может редактировать свои сообщения. Мол, сайт сообщает, что время редактирования вышло (там было две проверки: одна на сервере, другая на клиенте через JS). Оказалось, что у компьютера «кулхацкера» сдох элемент питания на встроенных часиках и после каждого выключения компьютера системные часы сбрасывались, а ntpupdate «кулхацкер» не осилил.

                    Так что полагаться на то, что у клиента установлено вменяемое время (я уже не говорю о том, что точное), не сто́ит.

                    *****

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

                    Кстати, все знают, как в Андроиде обновить эту таблицу, если патч для прошивки не вышел? Про tzdata вспомнили? А про ICU?
                    Ответить
                • Это все равно не оправдывает и не гарантирует правильности. А вот мне захотелось переключить время в то время как я пользовался сайтом? Просто не нужно так делать, и не нужно полагаться на то, что клиент пришлет будет правильным. Если очень хочется правильности: на сервере замеряли время когда отрпавили первый ответ и когда получили второй запрос, вообще не вовлекая в это клиента.

                  ПС. А если клиент из Альфа-Центавры, то что время на 50 лет переводить туда-обратно?
                  Ответить
                • > "это будет 5 минут спустя"

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

                  А ещё раздражает Инстаграм своим «это было 71 неделю назад». 71 неделя — это сколько в нормальных единицах измерения? Это вообще зимой или летом было?

                  P.S. Пусть сюда зайдут веб-дизайнеры и пусть им будет стыдно.
                  Ответить
                  • Мне кажется им в принципе всегда стыдно
                    Ответить
                  • > раздражает относительное время в современных дизайнах
                    Мне кажется, хорошо бы абсолютное + относительное в скобках.
                    А для ГК - абсолютное, относительное и относительное относительно рожительского комментария.

                    Ответил Петя, 01.01.2015 (5 месяцев назад; через 40 секунд)
                    Ответить
                    • Для стока ГК лучше показывать только абсолютное. А то обновляется он редко, смотришь, а там: «1024-- только что». А по факту это было полдня назад.
                      Ответить
                      • "Только что" читается как "при последнем обновлении стока".
                        Ответить
                        • Быстрофикс для стока (user.css):
                          abbr.published::after {
                             content: attr(title);
                             color: black;
                          }
                          Ответить
            • А во времени пользователя отсчеты вести не судьба?
              Ответить
              • Во времени сервера тогда уж.
                Ответить
                • ну тут уж зависит от логики приложения. Суть в том, что не нужно время сервера сравнивать с временем клиента
                  Ответить
                  • Не нужно, если вся деятельность клиента ограничена одной сессией. Без хранения данных на сервере.
                    Ответить
                    • ? почему это?
                      Ответить
                      • Потому что клиент мобилен и многоустройственнен, а серверу нужно чёткое определение метки времени.
                        Ответить
                        • Так пусть свое время и пишет. в чем проблема?
                          Ответить
                          • Проблема в относительности. см. выше
                            Ответить
                            • Это вам на тот свет к Альберту Германовичу Эйнштейну
                              Ответить
                              • Клиент отправляет сообщение в 10:35 по своему клиентскому времени. Реальное время таймзоны клиента 10:32. Время сервера 8:32. Получаем время ТЗ клиента относительно сервера(10:32). Записываем. При открытии сообщения, написанного в 8:32 по серверу, в 16:12(сервер) отправляем клиенту вместе со временем сообщения еще и текущее время клиента по мнению сервера(18:12). На клиенте сравниваем время клиента(18:15) с тем временем, которое посчитал сервер. Разница +3 минуты к рассчитанному сервером, используем для расчета реального времени. Абсолютная синхронизация времени сервера с клиентом с погрешностью во время расчетов и передачи информации, учитывающая неправильно выставленные часы у клиента. Эти +3 минуты можно хранить и обновлять только если разница изменилась дабы каждый раз не таскать дату туда-сюда.
                                Ответить
                                • Первые предложения до открытия сообщения - для примера, показать что у клиента часы спешат. "Записываем." в смысле все пишем в любом серверном варианте который устроит
                                  Ответить
                                • Реальное 10:32 вместо кривого 10:35 никого напрягать не будет. А если будет - пускай идут нахуй или часы подводят. Не надо плодить сложные костыли там, где они нинужны.
                                  Ответить

    Добавить комментарий