Когда ты знаешь, что пистолет не только у тебя одного, а у всех в округе, он становится оружием самообороны, но никак не нападения — пистолет перестает быть преимуществом.
Если я правильно понял эту фразу, то я могу создать фишинговую страницу, и спокойно перехватывать данные для входа, пользователь ведь будет думать, что защищен от взлома сильнее, чем при вводе логина/пароля. Биндинг IP адресов при этом не сильно поможет: не каждый пользователь станет читать алерт.
Особенно «радует» фраза: «Any FakePage can open securelogin://#provider=RealPage&state=TheirState and once the user accepts the request it will be sent for state=TheirState, so attacker’s login request will be successful.».
var leftCR = a.getBoundingClientRect()[«left»];
var topCR = a.getBoundingClientRect()[«top»];
var widthCR = a.getBoundingClientRect()[«width»];
var bottomCR = a.getBoundingClientRect()[«bottom»];
Я отказался работать с getElementById() в тот момент когда понял что он выдергивает только одно значение. В теле страницы могут быть несколько элементов с одним id, при парсинге товарных агрегаторов я раз и навсегда отказался от getElementById(), и перешел на querySelector() и querySelectorAll()
Просто оставлю это здесь. Но, в конце концов, это ваш продукт, поэтому вам принимать окончательное решение в плане выбора способа, мы лишь советуем.
По поводу отдельного объекта для кэша — здесь все зависит от логики работы вашего расширения — но в виду того, что элементы на странице не могут возникать из ниоткуда, а создаются непосредственно js-скриптом, то можно ссылки на них помещать в отдельный объект, чтобы через него быстрее обращаться к элементам, даже посредством того же перебора. Хранение не сильно нагрузит память, т.к. в объекте или массиве будут храниться ссылки на объекты.
Вот здесь Вы не правы. Я создал массив папок из 200 элементов. Потом повесил на каждый элемент по обработчику события. В итоге Страница с действующим классом, начала подвисать при event'ах, а у меня очень даже нормальный ноутбук. И учитывая, что на странице может быть не один экземпляр класса мне пришлось переписать логику так чтобы event'ов было не так много.
Здесь я имел в виду контекстное меню.
Напишите, пожалуйста, пример того, как вы вешали слушателей (или дайте ссылку на него) — интересно взглянуть, т.к. у самого есть проект с достаточно большим числом объектов на странице, на каждом из которых висит отдельный слушатель, и пока тормозов и подвисаний замечено не было.
Ну, коль уж вы хотели конструктивной критики:
— не стоит вызывать getBoundingClientRect() для одного и того же элемента подряд строка за строкой — это добавляет нагрузку, лучше вынести в отдельную переменную первый запуск, а затем уже обращаться к свойствам;
— обращаться к свойствам объекта можно не только через квадратные скобки, но и через точку;
— document.getElementById('title') сработает быстрее, чем document.querySelector("#title") (так для всех обращений по id) (про window.title молчу, т.к. лучше про него забыть));
— для элементов, которые не меняются и к которым часто происходит обращение, лучше завести отдельный объект типа кэша, чтобы каждый раз через селекторы не обращаться (или в вашем случае можно «забиндить» слушателей событий на this, чтобы обращаться к тем же самым созданным div'ам);
— стили лучше менять с помощью классов — браузер в таком случае применяет сразу весь набор новых стилей, а не строчка за строчкой, каждый раз перерисовывая элемент;
— код лучше разнести по разным файлам, в зависимости от назначения;
— стили так же лучше вынести туда, где они должны быть, то есть в css-файлы;
— если появление дополнительных ненужных отступов заставляет вас писать в строку элементы html, то можно убрать шрифт для всей страницы (font-size:0px;), а включить его там, где он непосредственно нужен, чтобы красивее отобразить html-код;
— честно говоря, не понимаю, для чего вам end.js, лучше его удалить, а так же убрать из манифеста возможность редактировать страницу любого сайта — это вызовет больше доверия у потенциальных пользователей;
— структура рода [«Мои записки»,0] ведет к ненужной жесткости кода — вам потом понадобиться добавить еще какое-то свойство, придется расширять массив и менять функцию-обработчик, я бы советовал заменить на объект;
— очень много дублирования кода;
— на каждое нажатие клавиши вы запускаете перебор по всем div'ам — это ужасно — если вы хотите найти следующий (предыдущий) элемент за родителем абзаца, который находится в фокусе, пользуйтесь nextElementSibling /previousElementSibling, с проверкой на существование;
— вы сравниваете e.keyCode и e.which на одно и то же значение, используйте любой из них (лучше keyCode) и пользуйтесь своим switch по-нормальному на здоровье (если вдруг так уж случилось, что они у вас работают по-разному, то можно воспользоваться конструкциями вида key=e.keyCode||e.which);
— вместо одного универсального слушателя лучше вешать на каждый элемент свой и отдельно повесить на нажатие по контекстному меню на скрытие;
— и к детям лучше все-таки обращаться через children (childNodes).
Честно скажу, код особо не читал, написал только то, что сразу бросилось в глаза, поэтому есть ли в логике самого расширения какие-то ошибки и недочеты, не могу сказать (код отвлекает). Для чего используется focus на элементах p тоже не знаю, но, думаю, лучше обойтись без него.
Основным итогом будет следующий: не используйте querySelector как панацею, ищите более быстрые альтернативы, применяйте файлы html, js и css для тех целей, для которых они предназначаются, в манифесте должно быть перечислено только то, что используется (файлы, разрешения).
Пробовал «воригинале». Сервис для изучения английского хороший, но есть два основных НО:
1) субтитры на русском/английском не всегда совпадают иногда даже друг с другом, но они это вроде как исправляют;
2) качества фильма выбрать нельзя, всегда грузится максимальное, что даже их сервер сам по себе просто не успевает отдавать, особенно в выходные дни.
Поэтому решил для себя, что лучше смотреть просто в оригинальной озвучке (есть сервисы, которые это предлагают, гуглятся по запросу «фильмы в оригинале») без замедления и субтитров, но с возможностью регулировать качество видео и без задержек даже на максимальном.
Слишком часто последнее время попадается подобный код, который они гордо называют MVC, в качестве портфолио от соискателей.
Так что если вы новичок и хотите начать писать программы правильно, читайте дальше.
— array_shift слишком затратная функция (извлечь + сдвинуть все элементы с числовыми индексами), вместо нее лучше обращаться напрямую через [], либо, если так уж хочется удалять элементы из массива, то array_reverse + array_pop, а конкретно в вашем примере $result=explode('/',$route,3);
— Судя по тому, как добавляются файлы через require, документация к нему прочитана не была.
— Функция launchAction накладывает ограничения на названия файлов и классов.
— Об использовании двойных кавычек вообще молчу.
ИМХО: И представленный код не для новичков с его namespace и классами. Если вы действительно хотели написать гайд, начали бы с процедурного стиля.
Это до поры до времени, не все активизируются сразу после получения персональных данных. Иногда уходят годы, чтобы вы уже и забыли, откуда спамеры/взломщики могли получить данную информацию.
Блокировщики в таком случае напишут правила для отсева рекламных данных от обычных.
На что владельцы исправят рекламные данные так, что их нельзя отличить от обычных, будут использовать постоянно изменяющиеся обфусцированные JS-скрипты.
Тогда простые блокировщики будут просто ждать появления рекламы и просто загораживать ее, как было и ранее, а популярным придется писать свою нейросеть, которая будет учиться отделять обычные данные от рекламных, деобфусцируя скрипты на лету.
И эта битва не закончится никогда… разве что с появлением нового (старого) типа доставки рекламы без возможности отделения данных, как видеоряд, уже встроенный в основное видео, которые невозможно прокрутить.
За два последних года исходный код страницы в веб-версии Instagram кардинально менялся два раза (меняли названия переменных, содержание), плюс они могут добавлять и удалять пробелы в синтаксисе по своему усмотрению.
Ну и использовать explode для получения подстроки в строке, это по меньшей мере кощунство. Можно было применить substr+strpos, preg_match, strstr.
Минус свойства transform еще и в том, что, если вдруг вы захотите добавить элемент с position:fixed внутрь элемента с transform, то он будет вести себя как position:absolute. Пример.
Для проверки расчетов.
Для примера — все красные таблетки в правой руке, 10 таблеток (синих) в левой руке, 13 (красных) в правой (пример вашего расчета относительно моих условий):
Таблетка уже есть. Красная. Вероятность того, что я, взяв таблетку, получу красную — 56.52% (13 из 23). Вероятность того, что, выбирая таблетку, я возьму ее из левой руки — 43.48% (10 из 23). Из правой — 56.52% (100% — 43.48%). Вероятность, что взятая таблетка будет из левой руки и окажется красной — 0%. Вероятность, что взятая таблетка будет из правой руки и окажется красной — 56.52% (вот тут могу ошибаться). Всего вероятность взять красную таблетку равна 56.52% (13 из 23 и 0% + 56.52%). Вероятность того, что взятая красная таблетка была из правой руки — ?% (100% (судя по дальнейшему описанию) из 56.52% (то есть 56.52 %). Процент вероятности взять красную таблетку из правой (100%) от вероятности достать красную вообще(56,52%)). Результат расчетов в данном случае не совпал с ожиданием.
Если не прав, пожалуйста, напишите, как считать в таком случае. Именно считать, потому что ответ — 100% и так ясен из самого условия.
Честно говоря, в вероятностях не разбираюсь (и питона нет), однако попробуйте рассмотреть граничные условия, когда красные таблетки лежат только в правой или левой руке.
На Microsoft на самом деле все так же прекрасно отключается — достаточно использовать локальный профиль. Как писали уже в комментариях — вас никто не заставляет прикладывать паспорт. Камера так же отключается (закрывается листиком).
Эссе представляет собой лишь чье-то мнение (так же, как я высказал свое), и по его поводу могу сказать, что не стоит путать понятия «личная жизнь» и «мне нечего скрывать». Куда и как я трачу честно заработанные деньги (если при этом не нарушаю закон) — это мое личное дело, я не собираюсь делиться им со своим соседом, однако если органы, имеющие на это право, затребуют от моего банка подобную информацию, он ее им предоставит, и я об этом в курсе, т. к. доверил свои платежи этому банку, за ведение счета, некоторые банки, кстати, берут комиссию.
Что касается третьей стороны — то ей предоставляется информация общего характера. Например, что вы мужчина, чтобы не показывать вам рекламу женских прокладок или бритвенных станков, в этом случае и вы и третья сторона в плюсе — вам не показывают рекламу, которая вам не интересна, они не тратят деньги на лишние показы рекламы.
По поводу набора на клавиатуре в тексте указано, для чего конкретно это делается. Ведь точно так же при наборе слов в Гугле или Яндексе появляются подсказки. Для вашего же удобства.
Ах да, забыл добавить, я не защищаю корпорацию (мне самому не нравится, что случилось со шрифтами, и политика в отношении обновлений), однако я всего лишь хочу донести, что это обычный юридический документ, в котором корпорация сразу заранее информирует о том, какая информация собирается и для каких целей.
Попробуйте воспринять документ с точки зрения разработчиков ОС (или тех же рекламодателей).:
вы хотите улучшить сервис, сделать его более персонализированным, сделать его более удобным для использования, при этом следовать всем современным течениям, естественно для этого необходимо анализировать информацию о пользователе, без этого никуда.
Прошу воспринимать написанное лишь моим личным мнением, дабы остановить попытки его изменить, как я уже сказал, сейчас существуют альтернативы (даже для того же Фотошопа есть Gimp).
Лично мне кажется, что «отжав воду из вышеприведенного» на самом деле выглядит так:
— Мы собираем данные о вашем взаимодействии с нашими службами.
— Мы собираем данные о том, с кем вы контактируете, и с кем поддерживаете отношения, если вы пользуетесь службами Майкрософт для управления контактной информацией.
— Содержимое ваших документов, фотографий, музыкальных или видеоматериалов, которые вы загружаете в службы Майкрософт.
— Содержимое ваших сообщений, отправляемых или получаемых через службы Майкрософт.
Поэтому я согласен с Ильей Сачковым и Алексеем Марковым. Соглашение больше похоже на персонализацию сервисов и внедрение инноваций, нежели на слежку со стороны. Было бы это действительно слежкой (что запрещено), файлы анализировались и отдавались по запросу спец. служб не только те, что синхронизируются с OneDrive, но и любые другие с жесткого диска, что можно было бы связать с вторжением в личную жизнь.
Насколько мне известно, Google уже давным давно собирает всю личную информацию, переписку, и на этой основе строит показы рекламы, персонализирует поиск, а Google Now дает советы, что сегодня неплохо было бы взять зонтик, потому что через 10 минут около вашего подъезда пойдет дождь, а вы как раз опаздываете на встречу и отказались от вызова такси, и всем это нравится, а когда Майкрософт вдруг решила сделать то же самое, все вдруг засуетились.
К тому же никто не обязывает переходить на Windows 10, для тех, кому есть, что скрывать, уже давным давно существуют другие ОС и Даркнеты.
Конкретный пример не приведу, но опишу как реализую этот момент (отображение времени получения информации) сам с поправками на то, что описано в статье (неверно установленный часовой пояс, не настроенная синхронизация времени с ntp-сервером или провайдером, ручная установка неправильного времени на клиенте).
В первую очередь разделяем серверную и клиентскую части. Достаточно только того, что клиент знает, что время всех сообщений, пришедших с сервера, задано в UTC и знает точное серверное время (опять же в UTC) на момент загрузки скрипта:
var deltaUTC = ( new Date() ).getTime() - <?=microtime( true );?>;
Серверу же все равно, какое время у клиента, он все сообщения сохраняет в UTC (для php — это date_default_timezone_set('UTC') и date() (или time())).
Выдача сообщений происходит через обработчик на клиенте (JavaScript-интерфейс), где параметр времени преобразовывается в требуемое значение или с помощью prototype, приведу пример с обычной функцией:
var mydate = function ( date ) {
var time = new Date ( date );
time.setTime ( time.getTime() + deltaUTC );
/* в качестве возврата будем использовать значение в привычном для пользователя формате */
return time.toLocaleDateString() + ' ' + time.toLocaleTimeString();
};
Передача сообщений в обработчик может происходить как посредством AJAX, так и в момент загрузки самой страницы (данные представляют собой JavaScript объект).
Главное помнить, что серверное время является эталоном, и само значение лучше не менять в процессе преобразований.
Такой подход решает проблему, когда в одном и том же чате общаются люди из разных часовых поясов, для каждого из них время относительно их самих. И даже если они переедут в другую часовую зону или перенастроят часы, время на сайте изменится, чтобы остаться относительным для клиента.
Таким образом решается проблема «двух-этапного метода» — на сервер нет необходимости передавать данные о клиентском времени.
Почему Вы использовали Date.UTC вместо getTime()?
Функция так же возвращается значение миллисекунд, прошедших с полуночи 01.01.1970 в UTC.
И для вывода в mydate я советовал бы посмотреть в сторону toLocaleFormat. Сайт может быть для нескольких стран, а следовательно, и время должно выдаваться в разных форматах, привычных жителям той или иной страны.
Можно еще попробовать сделать замок с лепестками с двух сторон, как с прорезями в одной плоскости, так и в разных. Чтобы исключить печать и использование третьей детали.
Я имел в виду:
и
Просто оставлю это здесь. Но, в конце концов, это ваш продукт, поэтому вам принимать окончательное решение в плане выбора способа, мы лишь советуем.
По поводу отдельного объекта для кэша — здесь все зависит от логики работы вашего расширения — но в виду того, что элементы на странице не могут возникать из ниоткуда, а создаются непосредственно js-скриптом, то можно ссылки на них помещать в отдельный объект, чтобы через него быстрее обращаться к элементам, даже посредством того же перебора. Хранение не сильно нагрузит память, т.к. в объекте или массиве будут храниться ссылки на объекты.
По поводу «биндинга» — Привязка контекста и карринг: «bind».
Здесь я имел в виду контекстное меню.
Напишите, пожалуйста, пример того, как вы вешали слушателей (или дайте ссылку на него) — интересно взглянуть, т.к. у самого есть проект с достаточно большим числом объектов на странице, на каждом из которых висит отдельный слушатель, и пока тормозов и подвисаний замечено не было.
— не стоит вызывать getBoundingClientRect() для одного и того же элемента подряд строка за строкой — это добавляет нагрузку, лучше вынести в отдельную переменную первый запуск, а затем уже обращаться к свойствам;
— обращаться к свойствам объекта можно не только через квадратные скобки, но и через точку;
— document.getElementById('title') сработает быстрее, чем document.querySelector("#title") (так для всех обращений по id) (про window.title молчу, т.к. лучше про него забыть));
— для элементов, которые не меняются и к которым часто происходит обращение, лучше завести отдельный объект типа кэша, чтобы каждый раз через селекторы не обращаться (или в вашем случае можно «забиндить» слушателей событий на this, чтобы обращаться к тем же самым созданным div'ам);
— стили лучше менять с помощью классов — браузер в таком случае применяет сразу весь набор новых стилей, а не строчка за строчкой, каждый раз перерисовывая элемент;
— код лучше разнести по разным файлам, в зависимости от назначения;
— стили так же лучше вынести туда, где они должны быть, то есть в css-файлы;
— если появление дополнительных ненужных отступов заставляет вас писать в строку элементы html, то можно убрать шрифт для всей страницы (font-size:0px;), а включить его там, где он непосредственно нужен, чтобы красивее отобразить html-код;
— честно говоря, не понимаю, для чего вам end.js, лучше его удалить, а так же убрать из манифеста возможность редактировать страницу любого сайта — это вызовет больше доверия у потенциальных пользователей;
— структура рода [«Мои записки»,0] ведет к ненужной жесткости кода — вам потом понадобиться добавить еще какое-то свойство, придется расширять массив и менять функцию-обработчик, я бы советовал заменить на объект;
— очень много дублирования кода;
— на каждое нажатие клавиши вы запускаете перебор по всем div'ам — это ужасно — если вы хотите найти следующий (предыдущий) элемент за родителем абзаца, который находится в фокусе, пользуйтесь nextElementSibling /previousElementSibling, с проверкой на существование;
— вы сравниваете e.keyCode и e.which на одно и то же значение, используйте любой из них (лучше keyCode) и пользуйтесь своим switch по-нормальному на здоровье (если вдруг так уж случилось, что они у вас работают по-разному, то можно воспользоваться конструкциями вида key=e.keyCode||e.which);
— вместо одного универсального слушателя лучше вешать на каждый элемент свой и отдельно повесить на нажатие по контекстному меню на скрытие;
— и к детям лучше все-таки обращаться через children (childNodes).
Честно скажу, код особо не читал, написал только то, что сразу бросилось в глаза, поэтому есть ли в логике самого расширения какие-то ошибки и недочеты, не могу сказать (код отвлекает). Для чего используется focus на элементах p тоже не знаю, но, думаю, лучше обойтись без него.
Основным итогом будет следующий: не используйте querySelector как панацею, ищите более быстрые альтернативы, применяйте файлы html, js и css для тех целей, для которых они предназначаются, в манифесте должно быть перечислено только то, что используется (файлы, разрешения).
1) субтитры на русском/английском не всегда совпадают иногда даже друг с другом, но они это вроде как исправляют;
2) качества фильма выбрать нельзя, всегда грузится максимальное, что даже их сервер сам по себе просто не успевает отдавать, особенно в выходные дни.
Поэтому решил для себя, что лучше смотреть просто в оригинальной озвучке (есть сервисы, которые это предлагают, гуглятся по запросу «фильмы в оригинале») без замедления и субтитров, но с возможностью регулировать качество видео и без задержек даже на максимальном.
— array_shift слишком затратная функция (извлечь + сдвинуть все элементы с числовыми индексами), вместо нее лучше обращаться напрямую через [], либо, если так уж хочется удалять элементы из массива, то array_reverse + array_pop, а конкретно в вашем примере $result=explode('/',$route,3);
— Судя по тому, как добавляются файлы через require, документация к нему прочитана не была.
— Функция launchAction накладывает ограничения на названия файлов и классов.
— Об использовании двойных кавычек вообще молчу.
ИМХО: И представленный код не для новичков с его namespace и классами. Если вы действительно хотели написать гайд, начали бы с процедурного стиля.
На что владельцы исправят рекламные данные так, что их нельзя отличить от обычных, будут использовать постоянно изменяющиеся обфусцированные JS-скрипты.
Тогда простые блокировщики будут просто ждать появления рекламы и просто загораживать ее, как было и ранее, а популярным придется писать свою нейросеть, которая будет учиться отделять обычные данные от рекламных, деобфусцируя скрипты на лету.
И эта битва не закончится никогда… разве что с появлением нового (старого) типа доставки рекламы без возможности отделения данных, как видеоряд, уже встроенный в основное видео, которые невозможно прокрутить.
Ну и использовать explode для получения подстроки в строке, это по меньшей мере кощунство. Можно было применить substr+strpos, preg_match, strstr.
Отключение/Включение AdBlock'а помогает, но только на один раз.
Для примера — все красные таблетки в правой руке, 10 таблеток (синих) в левой руке, 13 (красных) в правой (пример вашего расчета относительно моих условий):
Таблетка уже есть. Красная. Вероятность того, что я, взяв таблетку, получу красную — 56.52% (13 из 23). Вероятность того, что, выбирая таблетку, я возьму ее из левой руки — 43.48% (10 из 23). Из правой — 56.52% (100% — 43.48%). Вероятность, что взятая таблетка будет из левой руки и окажется красной — 0%. Вероятность, что взятая таблетка будет из правой руки и окажется красной — 56.52% (вот тут могу ошибаться). Всего вероятность взять красную таблетку равна 56.52% (13 из 23 и 0% + 56.52%). Вероятность того, что взятая красная таблетка была из правой руки — ?% (100% (судя по дальнейшему описанию) из 56.52% (то есть 56.52 %). Процент вероятности взять красную таблетку из правой (100%) от вероятности достать красную вообще(56,52%)). Результат расчетов в данном случае не совпал с ожиданием.
Если не прав, пожалуйста, напишите, как считать в таком случае. Именно считать, потому что ответ — 100% и так ясен из самого условия.
Эссе представляет собой лишь чье-то мнение (так же, как я высказал свое), и по его поводу могу сказать, что не стоит путать понятия «личная жизнь» и «мне нечего скрывать». Куда и как я трачу честно заработанные деньги (если при этом не нарушаю закон) — это мое личное дело, я не собираюсь делиться им со своим соседом, однако если органы, имеющие на это право, затребуют от моего банка подобную информацию, он ее им предоставит, и я об этом в курсе, т. к. доверил свои платежи этому банку, за ведение счета, некоторые банки, кстати, берут комиссию.
Что касается третьей стороны — то ей предоставляется информация общего характера. Например, что вы мужчина, чтобы не показывать вам рекламу женских прокладок или бритвенных станков, в этом случае и вы и третья сторона в плюсе — вам не показывают рекламу, которая вам не интересна, они не тратят деньги на лишние показы рекламы.
По поводу набора на клавиатуре в тексте указано, для чего конкретно это делается. Ведь точно так же при наборе слов в Гугле или Яндексе появляются подсказки. Для вашего же удобства.
Ах да, забыл добавить, я не защищаю корпорацию (мне самому не нравится, что случилось со шрифтами, и политика в отношении обновлений), однако я всего лишь хочу донести, что это обычный юридический документ, в котором корпорация сразу заранее информирует о том, какая информация собирается и для каких целей.
Попробуйте воспринять документ с точки зрения разработчиков ОС (или тех же рекламодателей).:
вы хотите улучшить сервис, сделать его более персонализированным, сделать его более удобным для использования, при этом следовать всем современным течениям, естественно для этого необходимо анализировать информацию о пользователе, без этого никуда.
Прошу воспринимать написанное лишь моим личным мнением, дабы остановить попытки его изменить, как я уже сказал, сейчас существуют альтернативы (даже для того же Фотошопа есть Gimp).
— Мы собираем данные о вашем взаимодействии с нашими службами.
— Мы собираем данные о том, с кем вы контактируете, и с кем поддерживаете отношения, если вы пользуетесь службами Майкрософт для управления контактной информацией.
— Содержимое ваших документов, фотографий, музыкальных или видеоматериалов, которые вы загружаете в службы Майкрософт.
— Содержимое ваших сообщений, отправляемых или получаемых через службы Майкрософт.
Поэтому я согласен с Ильей Сачковым и Алексеем Марковым. Соглашение больше похоже на персонализацию сервисов и внедрение инноваций, нежели на слежку со стороны. Было бы это действительно слежкой (что запрещено), файлы анализировались и отдавались по запросу спец. служб не только те, что синхронизируются с OneDrive, но и любые другие с жесткого диска, что можно было бы связать с вторжением в личную жизнь.
Насколько мне известно, Google уже давным давно собирает всю личную информацию, переписку, и на этой основе строит показы рекламы, персонализирует поиск, а Google Now дает советы, что сегодня неплохо было бы взять зонтик, потому что через 10 минут около вашего подъезда пойдет дождь, а вы как раз опаздываете на встречу и отказались от вызова такси, и всем это нравится, а когда Майкрософт вдруг решила сделать то же самое, все вдруг засуетились.
К тому же никто не обязывает переходить на Windows 10, для тех, кому есть, что скрывать, уже давным давно существуют другие ОС и Даркнеты.
В первую очередь разделяем серверную и клиентскую части. Достаточно только того, что клиент знает, что время всех сообщений, пришедших с сервера, задано в UTC и знает точное серверное время (опять же в UTC) на момент загрузки скрипта:
Серверу же все равно, какое время у клиента, он все сообщения сохраняет в UTC (для php — это date_default_timezone_set('UTC') и date() (или time())).
Выдача сообщений происходит через обработчик на клиенте (JavaScript-интерфейс), где параметр времени преобразовывается в требуемое значение или с помощью prototype, приведу пример с обычной функцией:
Передача сообщений в обработчик может происходить как посредством AJAX, так и в момент загрузки самой страницы (данные представляют собой JavaScript объект).
Главное помнить, что серверное время является эталоном, и само значение лучше не менять в процессе преобразований.
Такой подход решает проблему, когда в одном и том же чате общаются люди из разных часовых поясов, для каждого из них время относительно их самих. И даже если они переедут в другую часовую зону или перенастроят часы, время на сайте изменится, чтобы остаться относительным для клиента.
Таким образом решается проблема «двух-этапного метода» — на сервер нет необходимости передавать данные о клиентском времени.
Функция так же возвращается значение миллисекунд, прошедших с полуночи 01.01.1970 в UTC.
И для вывода в mydate я советовал бы посмотреть в сторону toLocaleFormat. Сайт может быть для нескольких стран, а следовательно, и время должно выдаваться в разных форматах, привычных жителям той или иной страны.