Как это не влияет? devicePixelRatio как раз определяет размер css пикселя, чем больше devicePixelRatio, тем больше css пиксель, тем больше размер шрифта если он задан в px.
Это все косвенные методы определения расстояния до глаз, десктопный монитор может быть развернут вертикально и иметь ширину как у планшета, и с поддержкой touch. На самом деле простым разработчикам и не нужно этого делать, производители девайса, будь то монитор, телевизор, ноутбук, планшет, телефон, в кооперации с разработчиками браузеров, должны подумать про это за нас и проставить правильный devicePixelRatio. Или даже давать пользователю возможность поменять его для разных вариантов использования одного и того же устройства.
А от разработчика просто требуется указать размер в px безо всяких ухищрений.
Надеюсь картинка с w3c продемонстрирует наглядно что я имею ввиду.
В браузерах есть возможность поменять базовый размер шрифта в настройках, но если шрифт на сайте задан жестко в px, то эта настройка ничего не поменяет
Мне всегда казалось что верным подходом является задание размеров шрифтов в px (ну или в rem если хотим позволить пользователю менять базовый размер), так как именно эта единица отражает угловой размер элемента в поле зрения пользователя. Т.е. в идеале шрифт будет одинаково смотреться как на большом экране так и на маленьком, как далеко от глаз пользователя, так и близко, как при большой так и при низкой плотности физических пикселей.
Однако чтобы это работало, устройства должны корректно проставлять свойство devicePixelRatio с учетом плотности физических пикселей и среднего расстояния до глаз при пользовании устройством. Но к сожалению мало кто из производителей устройств заботится об этом.
Внутри эти готовые типы (по крайней мере "Дата и время" из вашей классификации) скорее всего и хранят unix timestamp, или какую-то подобную метку времени. Просто во многих случаях гораздо удобнее мыслить timestamp-ами, так как они представляют собой просто абсолютный момент времени во вселенной, независимо от временной зоны, тогда не приходится говорить ни о каких конвертациях, вы просто сравниваете числа, передаете числа из одной зоны в другую, применяете ту или иную таймзону для отображения timestamp-а.
В таком случае не очень понятно, какие претензии у Oracle, если Android и так использует open source реализацию? И что поменяется от перехода от одной open source реализации к другой?
Немного разобравшись в теме стало понятно, что операции сложения и умножения в java действительно выполняются корректно как для знакового так и для беззнакового представления числа, так как используется дополнительный код. Это отнюдь не очевидно.
Все же помимо умножения и сложения есть еще деление и остаток от деления, не понимаю почему вы назвали это извратом, мы ведь не только о маске флагов говорим, мы можем работать со значением счетчика например.
Еще есть сравнение, преобразование в строку, которые тоже не одинаково выполняются для знакового и беззнакового представлений, да мало ли какие еще операции можно придумать. Навскидку — задание длины массива, размера буфера.
Не зря ведь в java se 8 добавили методы по ссылке выше.
Если java считает число знаковым, а разработчик беззнаковым — надо думать над каждой операцией, правильно она сработает или нет.
Самый безопасный способ — преобразовать в переменную более широкого знакового типа, что влечет больший расход памяти, но избавляет от массы других проблем.
Ну например чтобы производить арифметические действия придется использовать больше памяти, постоянно конвертировать, следить за переполнением, помнить об операторе >>> и т.п. Видел в некоторых библиотеках попытки формализовать все это, вынести типовые операции в статические методы.
Погуглив, обнаружил что в java 8 добавили такие методы, что радует!
В подписи к видео написано, что после отделения Филы Розетта делает маневр для поддержания Филы в зоне видимости, далее идет серия маневров для чтобы поменять сторону вращения, и далее Розетта уменьшает радиус орбиты. Наверное такая орбита будет оптимальнее для дальнейшего полета, коммуникации, фотографирования.
Да, интересная вещь. Но это скорее на очередной костыль похоже, который просто чисто технически приносит меньше неприятностей. UTC основан все-таки на атомной секунде. И в идеале программная реализация UTC должна знать что между «2012-06-30 23:59:59 UTC» и «2012-07-01 00:00:00 UTC» прошло 2 секунды.
Согласен, но в таком случае некоторые моменты выглядят не очень логично, нарпимер
Если вам нужно хранить время в прошлом или в будущем, сохраняйте локальное время пользователя, а рядом сохраняйте его таймзону. А ещё лучше, так, чтобы наверняка, сохраняйте географическое положение пользователя. Если нужно делать выборки по этому времени, сохраняйте рядом время в UTC, и обновляйте это время при изменении информации о часовом поясе.
Это совершенно излишне, лучше использовать timestamp with timezone, который выражаясь в ваших понятиях хранит «время в UTC» и таймзону. Преимущества я уже называл, сравнивать с другими timestamp with timezone-ами очень легко, ничего не надо конвертировать, просто сравнение двух чисел. Географические координаты тут скорее всего не пригодятся, так как именованные таймзоны (не аббревиатуры вроде MSK, MSD, а «Europe/Moscow») уже привязаны к географическому месту.
И вещи вроде «перевод в UTC», «перевод в локальную таймзону» смысла не несут, всегда хранится timestamp и опционально таймзона, которая используется для некоторых операций, в таком случае конвертация не нужна в принципе. Мы просто применяем таймзону к timestamp-у.
Я не говорю что что-то неверно в вашей статье, я говорю что представлять дату не в виде строки или объекта (как в вашей статье), а в виде числа гораздо удобнее и проще для понимания.
Длительность секунды (а следовательно и миллисекунды) строго константна, и определена как 9192631770 периодов излучения атома цезия-133, так что свое утверждение я считаю вполне обоснованным.
Вот длительность минуты из-за leap second может различаться, что безусловно создает массу проблем.
Москва перешла с UTC+4 на UTC+3, соответственно через секунду после «2014-10-26 01:59:59» стало опять «2014-10-26 01:00:00», далее прошел еще час (3600 секунд) и стало «2014-10-26 02:00:00», что в итоге и дало 3601 секунду в вашем примере. Так как мы имеем одно и то же строковое представление времени для разных моментов времени («2014-10-26 01:00:00» до и после перевода часов), библиотека не может понять какой именно момент вы имеете ввиду и берет например более ранний, что должно быть задокументированно.
Также бывает что из-за перевода часов вперед для какого-то на первый взгляд корректного строкового представления времени нету определенного момента времени (этот час просто пропустили, перевели стрелки), тогда хорошая библиотека должна сообщить об ошибке.
Посмотрел. Противоречий с тем что я написал не нашел. Если вы про leap second — с этим как я понял пока вообще все сложно, мало где она поддерживается. И наличие leap second никак не противоречит концепции timestamp как количества миллисекунд с определенного момента времени. Просто преобразование из timestamp в форматированную дату должно будет поддерживать историю изменений leap second.
Попробуйте перевести время «2014-10-26 01:30:00» в таймзоне «Europe/Moscow» в UNIX-timestamp?
jsfiddle.net/rq9vwobz/
Тут используется js библиотека moment.js. Для даты в таймзоне 'Europe/Moscow' и в UTC таймзоне внутри хранится один timestamp (по прежнему один момент времени), но разный offset, который влияет на отображение.
Мне кажется вы немного не теми понятиями оперируете, и поэтому все выглядит так сложно. Гораздо проще оперировать понятием timestamp — количество миллисекунд с 1 января 1970 года 00:00 UTC. Это с точностью до миллисекунды соответствует определенному моменту времени во вселенной, не зависимо ни от каких таймзон. Тем более почти все СУБД и языки представляют дату в памяти именно так. Сравнивать timestamp-ы между собой так же просто как числа, тут тоже не нужны никакие таймзоны.
Таймзоны становятся нужны когда вам нужно отобразить дату для пользователя, получить дату от пользователя, оперировать частями даты (час, минута, день, месяц, год, и т.п.). В таком случае есть 2 подхода:
1. Вы можете использовать везде одну таймзону (серверную), сказать пользователю что все отображается в этой таймзоне, все операции в запросах БД и в программе по умолчанию оперируют в серверной таймзоне, телодвижений практически не требуется.
2. Где-то хранить разные таймзоны, они могут быть привязаны к пользователю, могут быть привязаны отдельно к каждому полю с датой в БД. Благо многие СУБД и языки поддерживают типы данных timezone и timestamp with timezone.
Сравнивать timestamp-ы с разными таймзонами все так же просто, внутренний timestamp ведь одинаков, это все еще абсолютный момент времени, просто с дополнительной информацией о смещении. Для отображения, конвертации из строки, операций с частями даты как правило существует полный набор встроенных средств в СУБД или в библиотеку языка программирования. Все переходы на летнее/зимнее время, смены часовых поясов обрабатываются автоматически, обновления приходят с обновлениями ОС, СУБД или библиотек, так что при правильно написанном коде заботиться об этом практически не нужно.
В angular ui bootstrap для модальных окон используют сервис, вместо директивы. Шаблон для модального окна передается в метод сервиса. Мне кажется, это более логичный подход для модальных окон, так как модальное окно как правило нужно открывать по какому-то событию, нежели привязывать жестко к значению какого-то логического выражения. Ну и модальное окно по логике не вписывается в шаблон основного документа, оно существует отдельно, и соответственно в dom должно быть тоже отдельно.
Почему вы пишете, что в Node.JS используется модель N:1? Там же нет никаких потоков даже в userspace.
Это все косвенные методы определения расстояния до глаз, десктопный монитор может быть развернут вертикально и иметь ширину как у планшета, и с поддержкой touch. На самом деле простым разработчикам и не нужно этого делать, производители девайса, будь то монитор, телевизор, ноутбук, планшет, телефон, в кооперации с разработчиками браузеров, должны подумать про это за нас и проставить правильный devicePixelRatio. Или даже давать пользователю возможность поменять его для разных вариантов использования одного и того же устройства.
А от разработчика просто требуется указать размер в px безо всяких ухищрений.
Однако чтобы это работало, устройства должны корректно проставлять свойство devicePixelRatio с учетом плотности физических пикселей и среднего расстояния до глаз при пользовании устройством. Но к сожалению мало кто из производителей устройств заботится об этом.
Все же помимо умножения и сложения есть еще деление и остаток от деления, не понимаю почему вы назвали это извратом, мы ведь не только о маске флагов говорим, мы можем работать со значением счетчика например.
Еще есть сравнение, преобразование в строку, которые тоже не одинаково выполняются для знакового и беззнакового представлений, да мало ли какие еще операции можно придумать. Навскидку — задание длины массива, размера буфера.
Не зря ведь в java se 8 добавили методы по ссылке выше.
Если java считает число знаковым, а разработчик беззнаковым — надо думать над каждой операцией, правильно она сработает или нет.
Самый безопасный способ — преобразовать в переменную более широкого знакового типа, что влечет больший расход памяти, но избавляет от массы других проблем.
Погуглив, обнаружил что в java 8 добавили такие методы, что радует!
Это совершенно излишне, лучше использовать timestamp with timezone, который выражаясь в ваших понятиях хранит «время в UTC» и таймзону. Преимущества я уже называл, сравнивать с другими timestamp with timezone-ами очень легко, ничего не надо конвертировать, просто сравнение двух чисел. Географические координаты тут скорее всего не пригодятся, так как именованные таймзоны (не аббревиатуры вроде MSK, MSD, а «Europe/Moscow») уже привязаны к географическому месту.
И вещи вроде «перевод в UTC», «перевод в локальную таймзону» смысла не несут, всегда хранится timestamp и опционально таймзона, которая используется для некоторых операций, в таком случае конвертация не нужна в принципе. Мы просто применяем таймзону к timestamp-у.
Я не говорю что что-то неверно в вашей статье, я говорю что представлять дату не в виде строки или объекта (как в вашей статье), а в виде числа гораздо удобнее и проще для понимания.
Вот длительность минуты из-за leap second может различаться, что безусловно создает массу проблем.
Также бывает что из-за перевода часов вперед для какого-то на первый взгляд корректного строкового представления времени нету определенного момента времени (этот час просто пропустили, перевели стрелки), тогда хорошая библиотека должна сообщить об ошибке.
jsfiddle.net/rq9vwobz/
Тут используется js библиотека moment.js. Для даты в таймзоне 'Europe/Moscow' и в UTC таймзоне внутри хранится один timestamp (по прежнему один момент времени), но разный offset, который влияет на отображение.
Таймзоны становятся нужны когда вам нужно отобразить дату для пользователя, получить дату от пользователя, оперировать частями даты (час, минута, день, месяц, год, и т.п.). В таком случае есть 2 подхода:
1. Вы можете использовать везде одну таймзону (серверную), сказать пользователю что все отображается в этой таймзоне, все операции в запросах БД и в программе по умолчанию оперируют в серверной таймзоне, телодвижений практически не требуется.
2. Где-то хранить разные таймзоны, они могут быть привязаны к пользователю, могут быть привязаны отдельно к каждому полю с датой в БД. Благо многие СУБД и языки поддерживают типы данных timezone и timestamp with timezone.
Сравнивать timestamp-ы с разными таймзонами все так же просто, внутренний timestamp ведь одинаков, это все еще абсолютный момент времени, просто с дополнительной информацией о смещении. Для отображения, конвертации из строки, операций с частями даты как правило существует полный набор встроенных средств в СУБД или в библиотеку языка программирования. Все переходы на летнее/зимнее время, смены часовых поясов обрабатываются автоматически, обновления приходят с обновлениями ОС, СУБД или библиотек, так что при правильно написанном коде заботиться об этом практически не нужно.