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

    • ava bot 07.04.2015 21:00 # +1

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

      • ava inkanus-gray 13.05.2015 19:56 # 0

        Для пыха даже вышло расширение timezonedb, потому что он не использует системную таблицу и без переконпеляции в нём часовые пояса не обновить.

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

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

        «Штатные» функции преобразования времени — зло. Даёшь велосипеды!
        Ответить

    • ava Her 08.04.2015 00:03 # +1

      Давно пора все даты хранить в UTC. А на клиенте добавлять 
      new Date().getTimezoneOffset()
      Ответить

      • ava bot 08.04.2015 08:48 # 0

        Хрена лысого. На клиенте может быть плюс-минус несколько часов. Иногда спасал фарш в виде передачи дат строками, с последующим парсингом на клиенте при известной таймзоне сервера.
        Ответить

        • ava wvxvw 08.04.2015 09:33 # +2

          Ну и зачем так делать? Если у клиент "неправильное" время - может он так и хотел? Зачем пытаться угадать то, что в действительности нельзя угадать, вместо того, чтобы сделать правильно и оставить клиенту право выбора?
          Ответить

          • ava bot 08.04.2015 11:26 # −2

            Для синхронизации времени между клиентом и сервером. И для генерации на клиенте: "это было 5 минут назад".
            Ответить

            • ava wvxvw 08.04.2015 11:47 # +3

              И зачем для этого переводить время в клиентское вообще?
              Ответить

              • ava bot 08.04.2015 13:11 # 0

                Потому что данные хранятся на сервере. Клиент получает пачку данных с местным временем сервера. Если использовать UTC, то на клиенте может получиться "это будет 5 минут спустя".
                Ответить

                • ava bormand 08.04.2015 13:14 # +1

                  Если у клиента правильное UTC, сервер хранит в UTC и отправляет в UTC - всё будет заебись в любом случае. Локальный пояс может быть совершенно любым, какой ему больше нравится.

                  Если у клиента неправильное UTC - ССЗБ, пусть настраивает. Можно даже ему об этом намекнуть в каком-нибудь всплывающем сообщении.
                  Ответить

                  • ava bot 08.04.2015 13:15 # +1

                    Здесь не всё так однозначно. Клиент, как правило, считает, что это приложение глючит.
                    Ответить

                  • ava Arris 13.05.2015 16:21 # +1

                    У клиента? Правильное UTC? Многие клиенты, уверен, такого слова то не знают!

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

                    Реальный диалог, между прочим)
                    Ответить

                  • ava inkanus-gray 13.05.2015 19:47 # 0

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

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

                    *****

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

                    Кстати, все знают, как в Андроиде обновить эту таблицу, если патч для прошивки не вышел? Про tzdata вспомнили? А про ICU?
                    Ответить

                • ava wvxvw 08.04.2015 15:02 # +1

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

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

                • ava inkanus-gray 13.05.2015 20:04 # 0

                  > "это будет 5 минут спустя"

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

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

                  P.S. Пусть сюда зайдут веб-дизайнеры и пусть им будет стыдно.
                  Ответить

                  • ava kegdan 13.05.2015 20:27 # 0

                    Мне кажется им в принципе всегда стыдно
                    Ответить

                  • ava 1024-- 14.05.2015 01:39 # 0

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

                    Ответил Петя, 01.01.2015 (5 месяцев назад; через 40 секунд)
                    Ответить

                    • ava inkanus-gray 14.05.2015 11:52 # 0

                      Для стока ГК лучше показывать только абсолютное. А то обновляется он редко, смотришь, а там: «1024-- только что». А по факту это было полдня назад.
                      Ответить

                      • ava bormand 14.05.2015 13:29 # 0

                        "Только что" читается как "при последнем обновлении стока".
                        Ответить

                        • ava inkanus-gray 14.05.2015 13:52 # 0

                          Быстрофикс для стока (user.css):
                          abbr.published::after {
   content: attr(title);
   color: black;
}
                          Ответить

            • ava kegdan 08.04.2015 12:36 # 0

              А во времени пользователя отсчеты вести не судьба?
              Ответить

              • ava bormand 08.04.2015 12:40 # 0

                Во времени сервера тогда уж.
                Ответить

                • ava kegdan 08.04.2015 12:41 # 0

                  ну тут уж зависит от логики приложения. Суть в том, что не нужно время сервера сравнивать с временем клиента
                  Ответить

                  • ava bot 08.04.2015 13:11 # 0

                    Не нужно, если вся деятельность клиента ограничена одной сессией. Без хранения данных на сервере.
                    Ответить

                    • ava kegdan 08.04.2015 13:16 # 0

                      ? почему это?
                      Ответить

                      • ava bot 08.04.2015 13:18 # 0

                        Потому что клиент мобилен и многоустройственнен, а серверу нужно чёткое определение метки времени.
                        Ответить

                        • ava kegdan 08.04.2015 13:31 # 0

                          Так пусть свое время и пишет. в чем проблема?
                          Ответить

                          • ava bot 08.04.2015 13:41 # 0

                            Проблема в относительности. см. выше
                            Ответить

                            • ava volhv 09.04.2015 13:56 # 0

                              Это вам на тот свет к Альберту Германовичу Эйнштейну
                              Ответить

                              • ava guest 12.05.2015 11:18 # −1

                                Клиент отправляет сообщение в 10:35 по своему клиентскому времени. Реальное время таймзоны клиента 10:32. Время сервера 8:32. Получаем время ТЗ клиента относительно сервера(10:32). Записываем. При открытии сообщения, написанного в 8:32 по серверу, в 16:12(сервер) отправляем клиенту вместе со временем сообщения еще и текущее время клиента по мнению сервера(18:12). На клиенте сравниваем время клиента(18:15) с тем временем, которое посчитал сервер. Разница +3 минуты к рассчитанному сервером, используем для расчета реального времени. Абсолютная синхронизация времени сервера с клиентом с погрешностью во время расчетов и передачи информации, учитывающая неправильно выставленные часы у клиента. Эти +3 минуты можно хранить и обновлять только если разница изменилась дабы каждый раз не таскать дату туда-сюда.
                                Ответить

                                • ava guest 12.05.2015 11:23 # 0

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

                                • ava bormand 12.05.2015 12:00 # +1

                                  Реальное 10:32 вместо кривого 10:35 никого напрягать не будет. А если будет - пускай идут нахуй или часы подводят. Не надо плодить сложные костыли там, где они нинужны.
                                  Ответить

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