Форум PHP

Ребята, подскажите как настроить правильное время в чате, которое отображается в окне сообщения?!

Что значит правильное, и что означает настроить?

И в каком чате?
вобще придется пользовать аджакс для передачи врем. пояса юзера…

Зачем аякс? Просто ЯваСкрипт...

можно

вобще придется пользовать аджакс для передачи врем. пояса юзера…
Стесняюсь спросить откуда эти данные будут браться?
И на самом деле, что имеется ввиду правильное время, оно везде правильное :)
Если имеется ввиду время которое на машине пользователя, то это элементарно JS, если серверное, то вы уж хозяин барин.

getTimezoneOffset()

getTimezoneOffset()
Вы думаете это имелось ввиду?
Думаю если человек знаком с ajax, таких вопросов бы не задавал.

Если нужно время локали для пользователя, то к чему его вообще передавать на сервер?

чтобы сервер выводил обработанные данные, можно это возложить и на JS...
насколько я понял, нужно выводить даты отправления сообщений, вот к ним этот offset и надо плюсовать

Не могли бы подробней по теме, в каком файле можно задать параметры времени!

Какие параметры? Вы бы сначала прояснили ситуацию - чего вам надо? Если вам надо знать смещение часового пояса клиента, это одно. Если вы хотите преобразовать время сервера для клиента, то совсем не обязательно запрашивать у него смещение временной зоны, достаточно передать временную метку сервера клиенту, а JS у клиента посчитает и вадаст дату согласно его временной зоне.

В чате время отправления сообщения пишется например 14:42 а на компе у меня время 23:42.
Ясно теперь?

Нет, не ясно.
Если вы будете при получении сообщения получать время сервера, и выводить это время, то для всех клиентов будет указываться время сервера.
Если на сервере время 14:42, а вы хотите чтобы у клиента было его время (23:42), то нужно отдать время сервера клиенту, для коррекции его посредством JS, и вывода.
Так чего у вас?

>Не могли бы подробней по теме, в каком файле можно задать параметры времени!
Вам не нужны подробности.
Вы хотите законченное решение.
Остается или писать авторам или надеяться на появление энтузиаста, которому бы не лень было разобраться конкретно с этим скриптом...

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

Я хочу, чтобы у клиента было его время (23:42), Как это сделать в js(не знаком)?

Вот с этого и надо было начинать, а то время неверное.... Оно везде верное.
Можно поступить следующим образом:
1. Получайте метку времени сервера соответствущую записи сообщения в базу: $time = time().
2. Получите на сервере смещение часового пояса, в секундах, разделив его на 60 сек, так как JS у клинета возвращает подобное в минутах. Сохраните это смещение: $offset = date("Z")/60.
3. Передавайте метку времени $time умноженную 1000 (так как в JS метки времени в миллисекундах) и смещение сервера как аргуметы для JS функции.
4. JS-функцией скорректировать время и вывести.
Все примерно так:

//это у вас, к примеру, элемент, куда нужно вывести время клиента <div><script>document.write(getLocaleDate(<? echo ($time * 1000) . "," . $offset; ?>))</script></div> //это JS-функция рассчитывающая время для клиента <script> function getLocaleDate(servertime, serveroffset) {   var dt = new Date(); //создаем объект Date   var localeoffset = dt.getTimezoneOffset(); //получаем смещение клиента   //определяем разницу смещений, работая с абсолютными значениями,   //т.к. смещение к востоку на JS отрицательное   var offset = serveroffset < Math.abs(localeoffset) ? Math.abs(serveroffset + localeoffset) : Math.abs(localeoffset) - serveroffset;   //суммируем метку времени клиента с полученным смещением   servertime += offset;   //по полученной метке создает объект Date   dt = new Date(servertime);   //если нужны ведущие нули в дате, добавляем их   var date = dt.getDate() < 10 ? "0"+dt.getDate() : dt.getDate();   var month = dt.getMonth()+1 < 10 ? "0"+(dt.getMonth()+1) : dt.getMonth()+1;   var hours = dt.getHours() < 10 ? "0"+dt.getHours() : dt.getHours();   var minutes = dt.getMinutes() < 10 ? "0"+dt.getMinutes() : dt.getMinutes();   var seconds = dt.getSeconds() < 10 ? "0"+dt.getSeconds() : dt.getSeconds();   //возвращаем строку даты клиента   return date+"."+month+"."+dt.getYear()+" "+hours+":"+minutes+":"+seconds; } </script>

Вот только одна вещь. Кто-то из Кемерово, в беседе, сказал мне, что у них часы не переводят на летнее время, и если это так, то надо как-то это проверять. В общем принцип таков, а остальное нужно проверить практически.

А это код с чата?

Это код супер чата! Вы что, издеваетесь? Это код, получающий по метке времени сервера, дату на клиенте. Например, если сервер в Мокве, и там время 30.06.2009 18:39:01, а я имею смещение GMT +9 и разницу с Москвой 6 часов, то передав с сервера метку его времени, я получу вышеприведенным способом у себя свое время: 01.07.2009 00:39:01.

спасибо! Что называется "врубился"

Это хорошо, что врубились. Далее можете подумать сами, и поступать иначе. Зная, что можно получать время как на сервере, так и на клиенте, в двух форматах - локальное и GMT (UTC), можно передавать клиенту локальное время сервера, и получать на клиенте локальное время клиента, как разницу локального времени сервера с временем UTC полученным на клиенте, или наоборот.

По-моему, Вы изрядно переусердствовали с логикой учета смещения пояса.

<html>  <head>  <script> function fill(x, n) { //функция форматирования целых чисел с заполнением нулями   var a = (""+(1000000000+x)); return a.substring(10-n, 10); } function tzfmt(ofs) { //функция форматирования временного смещения   var hh, mm, s = ofs < 0? "-" : "+";   if(s == "-") ofs = -ofs;   mm = ofs%60; hh = (ofs-mm)/60;   return s+fill(hh, 2)+fill(mm,2); } function getLocaleDate(servertime) { //функция форматирования unix-timestamp   var dt = new Date(servertime*1000); //создаем объект Date   var y = dt.getYear(), y1 = y > 99;   return  fill((y%100)+ (y1 ? 2000 : 0), 4)+"-"+fill(1+dt.getMonth(), 2)+"-"+fill(dt.getDate(), 2)+" "      +fill(dt.getHours(), 2)+":"+fill(dt.getMinutes(), 2)+":"+fill(dt.getSeconds(), 2)      +" (UTC"+tzfmt(-dt.getTimezoneOffset())+")"; }   </script>  </head>  <body>   <div><script>//это у вас, к примеру, элемент, куда нужно вывести время клиента     document.write(getLocaleDate(<?php echo (time());  ?>))    </script></div>   </body> </html>

В чем?

я добавил свой код.
В нем тоже дерьма хватает изрядно манипуляций, но все они играют цель чисто косметическую, и могут быть выкинуты без вреда для результата.
Логикой пересчета времени между зонами нагружен именно движок JS.

Пример, кторый я привел, показывает сам механиз, что от чего зависит. На самом деле, я бы вообще не так делал, а использовал в расчетах два формата времени, это гораздо проще.

PS. Кстати, проще уж тогда передавать в функцию метод, "клеить" в начало нуль и возвращать, чем заниматься рассчетами, а потом еще резать строку.)

Sim5, извините меня за грубость ради бога, но
а) применение констструкции Math.abs(localeoffset) показывает, что автор не понимает физики процесса. Смещение временной зоны - величина знаковая, и брать от нее модуль - примерно то же самое, как брать модуль от величины высоты объекта над уровнем моря. Приводит к потере смысла.
У меня до сих пор остается впечатление, что эту строку писали не Вы.
Ну не могли Вы написать такой чуши.

б) Чтобы разобраться в сути, я попытался запустить Ваш пример, и не смог.
Он выдает обычные ошибки неопределенных переменных.

в) тогда я написал свой пример, в котором этой свистопляски со знаками смещений нет, и всё делается по правилам. Он работает. на трех браузерах одинаково. Можете попробовать.

а) Trianon, вы человек умный, можете себе что нить и красивое написать, я разве имею что против?
б) Автор темы вообще нифига не соображает, что такое время. Я как мог, просто, так и показал ему - что взять, почему сделать так, чтобы получить необходимое.
с) На самом же деле, можно забыть об этом - есть две метки времени: локальная (часовой пояс), и независящая от часового пояса (GMT). И уж коли делать красиво, то нужно использовать эти метки.
б) Не знаю, что за ошики он у вас выдает и в чем, у меня пример работает.

а) я собственно и ответил Вам, почему так, как делаете Вы - делать нельзя.
Весьма вероятно. что ошибки в скрипте проявятся когда сервер/клиент/оба будут находиться в области отрицательных смещений зоны (например, где-то на американском континенте.)


б) нету двух меток. Метка величина линейная и абсолютная ( и в этом смысле привязана Гринвичу. Строго говоря, даже не к Гринвичу (который у некоторых ходит туда сюда на час вперед назад) , а к универсальному координатному времени UTC, которое в любом поясе отвечает Гринвичским часам без переводов осенью и весной.

Кроме этой линейной метки может быть еще человеческое представление времени. В виде HHMMSS . Оно (в отличие от метки ) всегда зависит от пояса, но опирается при этом не на пояс а на локаль - совокупность административных установок в конкретной географической области.

Как метка, так и HHMMSS могут быть как у сервера, так и у клиента.
Только метки одного события совпадают независимо от того, на каком сервере/клиенте они сохранены. Собственно, вследствие этого постулата и выходит выводить HHMMSS у всех клиентов корректно, не особо напрягаясь с пересчетом. Если конечно, пользоваться средствами клиента.

в) скриншот с ошибками сейчас прилеплю.

г) да. я знаю, что кое где в функциях php есть некоторые, которые unix-timestamp сдвигают относительно UTC . И считаю это ересью мерзкой.

е) автора темы можно понять. У него нехватка времени.

Я не рассчитываю на североамериканский континет, я, рассказывая это, расчитывал на русскую публику, не более того, как совсем не учитывал и "мертвых душ" в чате автора, так как навряд ли они у него есть, а тем более будут, за 1996 год. Поэтому, просто отнимаю от смещения сервера смещение клиента.

Говоря о метках, я имею ввиду время часового пояса, и время UTC, которое для всех часовых поясов будет одно и тоже. Вот и надо использовать эти две величины, уж коли делать по умному. РНР смещение к востоку дает положительное, к западу отрицательное, в JS же все наоборот, и его при расчете учитываем только как "направление". Надо будет мне, значит я буду делать именно так.

А вот автор пусть сидит и разбирается, что-то я сомневаюсь, что причина в нехватке времени у него :)

PS. Что касается ошибки. Денвер JS ошибки не контролирует, это прерогатива браузера, а в саму функцию я не делал вставку РНР-кода. Я этот пример забросил на московский сервер, и время +- от Москвы показывало верно.
Единственное, что никак не получится, это вывести время клиента, если его часы не переведены на летнее время, в отличие от сервера.

Sim5, я на Ваш вопрос ответил?

На:
для: Trianon (30.06.2009 в 20:17)
В чем?
?

именно

И еще, sim5, не откажите в любезности - забросьте мой код (без изменений) на этот московский сервер.
Что он покажет у Вас?
И что он покажет, если Вы снимете у себя флажок летнего времени?

Ради интереса могу сказать, по поводу кода от 30.06.2009 в 20:17.
При забросе скрипта на московский сервер, время обычное московское.
Если снять значок летнего времени на машине клиента, то время на час назад.

Ну естественно, так и будет.

>Ради интереса могу сказать, по поводу кода от 30.06.2009 в 20:17.
>При забросе скрипта на московский сервер, время обычное московское.
Меня интересовала ситуация у клинента на поясе, отличном от московского.
У sim5 как раз такая.
Собственно, вторично, но опять же если бы это посмотрел sim5, спор пришел бы к логическому завершению.

>Если снять значок летнего времени на машине клиента, то время на час назад.
Что происходит в одном поясе я могу и на денвере посмотреть.

А что был спор? Что же это я драку пропустил, пара синяков не помешала бы. :))
10 мин назад закончил свое, можно и пофлудить. И так:
1. Вопрос автора поставил в тупик - неправильное время, это когда часы в мастерскую надо (в общем не понял сперва)....
2. Предложение автору узнать у клиента смещение, не логичное, поэтому, между своей работой, решил быстро пример сделать - какими данными нужно оперировать, чтобы не зависить от клиента.
3. Нужен был кто-то (для проверки), живущий как и я "в минусе", но далее Москвы. С Киевом не получилось, ибо на Украине постоянно что-то не то... :)
4. Удача, дочь живущая в Загребе (GMT +1, JS -120), появилась в сети.
5. Вот тут быстренько и родилось следущее:

<html> <head> <script> function addZero(v) {   return v < 10 ? "0"+v : v; } function getLocaleDate(stime, soff) {   var dt = new Date();   var loff = dt.getTimezoneOffset()   var off = soff < Math.abs(loff) ? Math.abs(soff + loff) : Math.abs(loff) - soff;   stime += off;   dt = new Date(stime);   return addZero(dt.getDate())+"."+addZero(dt.getMonth()+1)+"."+dt.getYear()+" "+          addZero(dt.getHours())+":"+addZero(dt.getMinutes())+":"+addZero(dt.getSeconds()); } </script> </head> <body> <div><script>document.write(getLocaleDate(1246330661000, 14400/60))</script></div> </body> </html>

Было сброшено на московский сервер - у меня, и в Загребе все показывает как и следует. Ну а уже затем,.... зачем и почему, я и написал сюда.

Резюме. Я не знаю, собственно, о чем вы спорите, лично мне не до споров было последние две недели. Если касаемо подхода, так я уже сказал - действительно пригодится это, значит сделаю, но использовать методы буду иные. Если касемо североамериканцев и прочих их земляков, меня они на этот момент вообще не интересовали, да собственно и сейчас не интересуют.

А вот о летнем времени, тут точно, что-то съехало - ведь сам же все повторял автору, что нужно исходить из того, что отдать все клиенту, и сам грешным делом стал думать, как бы у клиента получить. :)

Теперь собственно в чем я пытаюсь Вас убедить.
Коротко.
Следующие строки

var dt = new Date();   var loff = dt.getTimezoneOffset()   var off = soff < Math.abs(loff) ? Math.abs(soff + loff) : Math.abs(loff) - soff;   stime += off;   dt = new Date(stime);

нужно заменить одной

var dt = new  Date(stime);

Для Trianon и Sim5

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

Потряссающие Вы люди :)

P.S. Так можно к Вам свой подход найти. Сказать что Вы не правы, и отстаивать свое мнение до последнего, пока в ответ не получишь полный мануал по конкретной проблеме :)
.

80% здешних посетителей вовсе не нуждаются чтоб их где-то во что-то чем-то тыкали.
Они хотят работающий (совершенно неважно как и почему) код.
При чем делают это в формате "пожалуйста, расскажите поподробнее".
Ровно ничего не давая взамен.
И никак не воспринимая эти самые подробности.

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

Вам конечно виднее, я тут недавно затусовался. А вообще, я просто пошутить немножко хотел, по ситуации так сказать.

Вот теперь я перечитал внимательно. То есть, UNIX timestamp, это метка времени, которая образно говоря, на локальном компьютере трактуется его временной зоной. А я не так представлял это, да собственно и использовал всегда до этого ее локально. Если бы я не забыл скорректировать смещение (на 1000), то сразу бы заметил несостыковку, и ошибочность рассуждений.
Полезно было, Trianon. Да и вообще полезно, хотя бы иногда, не "наскоком" читать, а останавливаться и вчитываться. Но реальное время диктует свое - его как всегда не хватает. :)

>Кто-то из Кемерово, в беседе, сказал мне, что у них часы не переводят на летнее время
Переводят. Правда тут есть одна деревня, сельсовет в которой решил на это дело наплевать. Вот они нет )))

Значит мне лапши на уши навешали :)