Как узнать есть ли в дате часовой пояс?
 

Дата задана строкой в ISO8601 или IETF RFC 2822 формате. Как узнать, что в ней указан часовой пояс, не парся строку?

var date1 = new Date('2000-01-05T23:59:59.000Z'); //UTC
var date2 = new Date('2000-01-05T23:59:59.000+03:00'); 

var date3 = new Date('Sat Jan 05 2000 23:59:59 GMT+0000 (MSK)'); //UTC
var date4 = new Date('Sat Jan 05 2000 23:59:59 GMT+0300 (MSK)');
var date5 = new Date('Sat Jan 05 2000 23:59:59'); //пользовательский пояс

console.log(date1, date2, date3, date4, date5)

А если без парсинга невозможно, то какими регулярками парсится?

https://developer.mozilla.org/ru/doc...TimezoneOffset
?

nerv_,
и как это поможет?

это как? )

Rise,
Sat, 25 Aug 2016 11:56:28 UTC - это формат UTC, возвращаемый методом toUTCString
Sat Aug 25 20:59:42 UTC+0540 2016 - дата/время возвращаемое методом toString
20:57:18 UTC+0300 - время возвращаемое методом toTimeString

А еще есть и ISO формат. И как больше/меньше/не равно 24?

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

Проверять наличие плюсика?)
Сама по себе просто задача непонятная.

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

тогда, если я правильно понял вопрос, так:

let arr = [
  '2000-01-05T23:59:59.000Z',
  '2000-01-05T23:59:59.000-03:30',
  '2000-01-05T23:59:59.000+04:15',
  'Sat Jan 05 2000 23:59:59 GMT-0400',
  'Sat Jan 05 2000 23:59:59 GMT+0000',
  'Sat Jan 05 2000 23:59:59 GMT+0400',
  'Sat Jan 05 2000 23:59:59'
];

for(let str of arr) {
	console.log(getTimeZoneOffset(str));
}

/**
* @see [url]https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Date/getTimezoneOffset[/url]
* @param {String} ds1 a date as string
* @returns {Number}
*/
function getTimeZoneOffset(ds1) {
  let isUTC = ds1.slice(-1) === 'Z';
  if (isUTC) {
  	return 0;
  }
  let ds2 = ds1.replace(/[-+]\d\d:?\d\d/, '');
  if (ds1 !== ds2) {
    let d1 = Date.parse(ds1);
  	let d2 = Date.parse(ds2);
    return (d2 - d1) / 1000 / 60;
  } else {
  	return new Date().getTimezoneOffset();
  }
}

UPD: http://momentjs.com/guides/#/lib-con...mezone-offset/

это не каша, это стандарты представления времени

Каша не в смысле напридумывали кучу, а отдавать в одном формате, а не в разнобой, в том случае если источник свой.

nerv_, Ну да, что-то типа того. Как понимаю, средствами языка смещение никак не вычислить. Только парсить.

laimas, в том-то и дело, что источник не свой. В общем виде, нужно написать функцию, сравнивающую две даты, которая будет принимать аргументы в пяти распространенных форматах: JS Date, time (кол-во мс с 1970), ISO8601, IETF RFC 2822 и moment.js date. Причем даты могут быть в разных форматах.

P.S. Вопрос на засыпку для извращенцев, что вернут выражения :-)

new Date(/14/)
new Date(/33/)

Invalid Date.

Если бы речь шла об едином мгновении времени и времени конкретного клиента, то хватило бы Date.parse().

Разбирать рег. выражением учитывая все форматы. На сервере, к примеру в РНР есть готовая функция date_parse(), возвращающая всю информацию о заданной дате/времени. Например для таких форматов 2000-01-05T23:59:59.000Z, 2000-01-05T23:59:59.000+04:15, Sat Jan 05 2000 23:59:59 GMT-0400 будет возвращено соответсвенно:

На 100% уверен?)

Как не извращенец да. Где изврат то? )

Что это такое - '\v'=='v', изврат или нет?

А я как по твоему сделал?)

nerv_,
почему 'Sat Jan 05 2000 23:59:59' не ноль тогда?

Оказалось, можно и без смещения всё сделать) Написал конвертер для дат https://github.com/tamtakoe/common-v...y.js#L694-L730, который преобразует даты любых форматов в UTC-дату, после чего их можно нормально сравнивать.

Позже в отдельный проект вынесу

А чем не устраивает тогда date_parse с strtotime?

Это так же глупо как использовать парсер для JSON, когда в JS есть встроенный :-) Тем более, не уверен, что эта библиотека будет нормально все ситуации обрабатывать. Она работает только со строками, тогда как половина сложностей была в сравнение моментовских дат и дат из таймстемпа

А что кроме метки времени или его отдельно взятого компоненте есть не строка в его представлении?

Не могу утверждать об аналоге, хотя можно и проверить, но оригинальная strtotime обрабатывает английскую нотацию выражений о времени и ей по плечу куда более прозаическое, чем "UTC или не UTC?". )

Не понял вопрос
Вот это как раз, вообще, пофигу) Если пользователь юзает какую-то свою нотацию времени из каких-то непонятных стандартов, пусть сам с этим и мучается. А вот UTC, не UTC это реальная проблема JS. К сожалению, до конца ее не решить, т.к. реализация отличается в ES5, ES6, в браузерах и даже на разных машинах может по-разному работать

С чего это вдруг?

Что не понятного, представление времени это всегда строка, за исключением штампа времени и конкретно взятого его компонента, например год. А strtotime и работает со строковым представлением, возвращая штамп времени.

Ну это как сказать, по крайней мере проще написать:

$day = date('d', strtotime('first day next week'));

чем разводить бухгалтерию вычислений.

Вы спутали системные часы и смещения часовых поясов. Системные часы и работают относительно Гринвича, достаточно указать другой часовой пояс системным часам и время изменится. Но время клиента, это локальное время. Например, если клиент получит время московского клиента как дата/время и дата/время/UTC, то на клиенте из этих дат будет возвращены метки времени - первая как локальное время клиента, а вторая с указанным смещением, и эти метки времени будут различны.

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

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

Выпустил модуль normalize-date. Приводит любую дату к нативной JS UTC (или эквивалентной UTC) дате.

Надеюсь, это избавит от проблем сравнения дат в 90% случаев