Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 28
По сравнению с moment, киллерфича — скорость?
Да, скорость, также можно привести возможность использовать месяцы с 1, а не 0 (там такого не увидел), генерацию дат и возможность задавать даты с помощью объектов, а не массивов, иногда это выглядит понятней.
Скорость — хорошо.
Месяцы с 1 плохо для поддержки кода новыми разработчиками, ибо отличается от нативной реализации.
Генерация может пригодиться, хотя пока не понимаю где.
momentjs.com/docs/#/parsing/object/
Месяцы с 1 плохо для поддержки кода новыми разработчиками, ибо отличается от нативной реализации.
Генерация может пригодиться, хотя пока не понимаю где.
momentjs.com/docs/#/parsing/object/
Месяцы с 1 плохо для поддержки кода новыми разработчиками, ибо отличается от нативной реализации.
Типичный холивар с 1 в месяцах в js :) Тут можно и использовать, и не использовать, все зависит от принятых в конкретном веб-приложении стандартов. Отключается вполне легко:
tempus.options('monthFromZero', true);
Генерация может пригодиться, хотя пока не понимаю где.
Мне, например, требуется настраиваемый календарик, который генерируется без участия сервера, а пользователь на нем может отмечать некоторые события, которые затем отправляются на сервер (дата-событие).
momentjs.com/docs/#/parsing/object/
Не видел, спасибо
А что с временными зонами?
Что именно вас интересует? На данный момент есть только геттер получения смещения, если требуется что-либо еще, например, названия временных зон или еще что-нибудь, то это всегда можно добавить.
А откуда берется смещение? Из локальной даты пользователя?
Пример: дата в базе в UTC, приходит с json, надо показать в локальной TZ (или даже в заданной, например локальное время другого пользователя).
Пример: дата в базе в UTC, приходит с json, надо показать в локальной TZ (или даже в заданной, например локальное время другого пользователя).
Да, из локальной даты. Требуется указать дату в конкретной таймзоне и работать уже с ней? Понял идею, запишу в issue, спасибо за отзыв! На данный момент это можно сделать так:
на выходе будет требуемая дата с любым смещением.
tempus(timestampUTCFromServer).calc({hours: timezoneOffsetFromServer});
на выходе будет требуемая дата с любым смещением.
>или даже в заданной, например локальное время другого пользователя
Для этого нужно табличку по временным зонам — когда кто на летнее время переводит, и т.п.
Вообще JS на клиенте не умеет еще очень много что нужно для зон — даже просто получить название зоны клиента нельзя, и даже если поизвращаться однозначно это сделать все равно не выйдет. И еще много косяков. Библиотечка бы под это не помешала.
Для этого нужно табличку по временным зонам — когда кто на летнее время переводит, и т.п.
Вообще JS на клиенте не умеет еще очень много что нужно для зон — даже просто получить название зоны клиента нельзя, и даже если поизвращаться однозначно это сделать все равно не выйдет. И еще много косяков. Библиотечка бы под это не помешала.
Спасибо за предложение, записал в задачи.
Вот кстати наличие работы с таймзонами — это очень нужная штука, и я чего-то не видел js-библиотек под это. Вот прямо сейчас запиливаем поддержку зон на клиента — все руками приходится делать.
Нужен как минимум:
— автодетект таймзоны пользователя. Это кстати весьма нетривиально и однозначно это сделать вроде нельзя. Я перевожу в UTC несколько локальных дат, и по смещениям и табличкам зон на сервере примерно угадываю (хотя так далеко не все зоны можно так разделить)
— какой-то механизм обновления информации о зонах (хотя бы через обновления библиотеки)
— собственно utcToLocal(zoneID, date) и localToUTC(zoneID, date)
Нужен как минимум:
— автодетект таймзоны пользователя. Это кстати весьма нетривиально и однозначно это сделать вроде нельзя. Я перевожу в UTC несколько локальных дат, и по смещениям и табличкам зон на сервере примерно угадываю (хотя так далеко не все зоны можно так разделить)
— какой-то механизм обновления информации о зонах (хотя бы через обновления библиотеки)
— собственно utcToLocal(zoneID, date) и localToUTC(zoneID, date)
Хотя вот такое нагуглилось — momentjs.com/timezone/data/
Спасибо, буду это осуществлять.
Тут можно попробовать использовать поиск по геолокации html5demos.com/geo (плохо, т.к. браузер спрашивает, можно ли запросить местоположение) или по IP www.ipinfodb.com/ (требуются большие базы или запросы) или использовать подобную мини библиотеку bitbucket.org/pellepim/jstimezonedetect/overview
— автодетект таймзоны пользователя. Это кстати весьма нетривиально и однозначно это сделать вроде нельзя
Тут можно попробовать использовать поиск по геолокации html5demos.com/geo (плохо, т.к. браузер спрашивает, можно ли запросить местоположение) или по IP www.ipinfodb.com/ (требуются большие базы или запросы) или использовать подобную мини библиотеку bitbucket.org/pellepim/jstimezonedetect/overview
Форматирование какое то у вас слабоватое. Как минимум нету миллисекунд, смещений временной зоны и тп. Как максимум нету возможности менять паддинги кроме 0 (01 -> 1 (вместо 0 использовать пробел например)).
На эту тему мне очень нравится как сделаны форматирование в java и в ruby (расширяетс С strftime).
На эту тему мне очень нравится как сделаны форматирование в java и в ruby (расширяетс С strftime).
На самом деле все легко расширяется через registerFormat. Для меня это самые частоиспользуемые форматы, а перегружать всем подряд не хотелось.
apidock.com/ruby/DateTime/strftime — выглядит интересно, спасибо! Как раз думал на тему подобных модификаторов, но решил подождать. Теперь есть от чего отталкиваться.
Еще бы неплохо добавить арифметику дат (с форматированием, естественно), например разность дат, или осталось X дней.
Почему вы используете такой синтаксис (я про проценты)?
Ведь без процентов могло бы быть совместимым с синтаксисом функции
Ведь без процентов могло бы быть совместимым с синтаксисом функции
date() в PHPМне ближе python'оподобное представление — docs.python.org/2/library/datetime.html#strftime-and-strptime-behavior и как то хотелось выделить директивы от просто текста. При синтаксисе без процентов, придется использовать слэши для экранирования, а в javascript использование слэшей обычно заканчивается чем-то таким \\\\' :-)
Отличная библиотека! Я так понял, сейчас нельзя добавить свои переводы, т.к. translations — локальная переменная.
Вобще было бы хорошо иметь возможность указать свою функцию перевода, чтобы хранить все переводы в одном месте. Что-то вроде
Вобще было бы хорошо иметь возможность указать свою функцию перевода, чтобы хранить все переводы в одном месте. Что-то вроде
tempus.translations = gettext // или I18n.tСпасибо! По поводу своей функции перевода — хорошая идея!
Думаю, что тогда надо делать так:
— переводы оформить как JSON-файл, который можно подключать отдельно (или вообще не подключать, если не требуется) — да и проще его изменить будет, используя только нужные переводы для конкретного сайта. Думаю, что лучше тогда будет генерировать также версию «все в одном».
— функция tempus.translate(text), которую можно перекрывать своей функцией — то, о чем вы сказали.
Думаю, что тогда надо делать так:
— переводы оформить как JSON-файл, который можно подключать отдельно (или вообще не подключать, если не требуется) — да и проще его изменить будет, используя только нужные переводы для конкретного сайта. Думаю, что лучше тогда будет генерировать также версию «все в одном».
— функция tempus.translate(text), которую можно перекрывать своей функцией — то, о чем вы сказали.
Вынес переводы в отдельный файл, лежит рядом с библиотекой — translations.json. Переводы можно использовать в нем. Также, этот файл автоматом подгружается из той же директории, где и библиотека. Можно запретить автоподгрузку, если использовать следующий вид подключения скрипта:
т.е. с GET-параметром loadTranslations=false. В иных случаях подгружается. Также, можно руками подгрузить переводы из объекта или по урлу из JSON-файла, используя функцию loadTranslations — docs.tempusjs.org/documentation/docs/tempus/tempus.global:loadTranslations
<script type="text/javascript" src="src/tempus.js?loadTranslations=false"></script>
т.е. с GET-параметром loadTranslations=false. В иных случаях подгружается. Также, можно руками подгрузить переводы из объекта или по урлу из JSON-файла, используя функцию loadTranslations — docs.tempusjs.org/documentation/docs/tempus/tempus.global:loadTranslations
Всегда пользовался www.datejs.com попробую на досуге ваш вариант. Киллерфичей считаю цепочки.
нативным способом форматирования даты
Вы упустили новый нативный Intl.DateTimeFormat. Лучше бы на него ориентироваться.
Спасибо за ссылку. Он пока мало где поддерживается, но обратить внимание определенно стоит.
Как это «мало»? Да практически везде на десктопе, кроме «Файерфокса». Что для меня особенно огорчительно, но можно использовать самописный или готовый полифилл.
Ориентировался на табличку по вашей ссылке developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat#Browser_compatibility
Если верить ей, то в FF и Safari вообще не поддерживается, в IE только последнем, а на мобильных вообще никто, кроме хрома, не поддерживает. Это имел в виду.
Вообще, как я понял, там нельзя сделать свое форматирование? Только передаешь локаль и что показывать:
Пример отсюда: developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat#Example:_Using_options
Вообще, тут есть один большой плюс — можно не заморачиваться и отображать дату в понятном и привычном человеку формате минимум усилий, но и такой же минус — если потребуется сделать шаг в сторону, где потребуется немного другое форматирование, то это не получится. Я правильно понял?
Мне кажется, что это не очень удобно и лучше бы сделали реализацию как в других ЯП. Ну и плюсом, если его включать в свое веб-приложение, то в остальных браузерах придется реализовывать аналогичное представление своим способом и надо учитывать все локали, на которых это приложение будет использоваться и тестировать всевозможные комбинации форматов — где, что и как он отображает.
Вот это меня и смущает. Если неправильно понял описание и примеры, то не могли бы вы пояснить?
Если верить ей, то в FF и Safari вообще не поддерживается, в IE только последнем, а на мобильных вообще никто, кроме хрома, не поддерживает. Это имел в виду.
Вообще, как я понял, там нельзя сделать свое форматирование? Только передаешь локаль и что показывать:
var date = new Date(Date.UTC(2012, 11, 20, 3, 0, 0));
var options = {weekday: "long", year: "numeric", month: "long", day: "numeric"};
alert(new Intl.DateTimeFormat("de-DE", options).format(date));
// → "Donnerstag, 20. Dezember 2012"
Пример отсюда: developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat#Example:_Using_options
Вообще, тут есть один большой плюс — можно не заморачиваться и отображать дату в понятном и привычном человеку формате минимум усилий, но и такой же минус — если потребуется сделать шаг в сторону, где потребуется немного другое форматирование, то это не получится. Я правильно понял?
Мне кажется, что это не очень удобно и лучше бы сделали реализацию как в других ЯП. Ну и плюсом, если его включать в свое веб-приложение, то в остальных браузерах придется реализовывать аналогичное представление своим способом и надо учитывать все локали, на которых это приложение будет использоваться и тестировать всевозможные комбинации форматов — где, что и как он отображает.
Вот это меня и смущает. Если неправильно понял описание и примеры, то не могли бы вы пояснить?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
TempusJS — работаем с датой в javascript