Момент, не дающий одинаковых значений
var a = moment().toISOString(true)
var b = moment();
var c = moment(b.toISOString(true));
console.info(a);// 2024-04-15T00:09:47.226+01:00 --->here time is one hour ahead
console.info(b);//"2024-04-14T23:09:47.472Z"
console.info(c);//"2024-04-14T23:09:47.472Z"
Пожалуйста, помогите мне понять следующее
![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)
Ответы 1
2024-04-14T12:00:00.000Z
2024-04-14T13:00:00.000+01:00
Обе эти строки ISO относятся к одному и тому же абсолютному моменту времени, обычно называемому моментом. Оба они соответствуют времени Unix 1713096000000.
Они различаются информацией о часовом поясе. Обе (!) являются зонированными , первая строка находится в формате UTC (фиксированное смещение +00:00), обозначается Z в конце, а вторая имеет смещение часового пояса +01:00. Также следует отметить: смещение часового пояса — это не то же самое, что часовой пояс, но это различие не имеет значения для данного конкретного использования.
Оба представления верны относительно своего абсолютного времени. Какой из них подходит, зависит от того, соответствует ли смещение часового пояса потребностям вашего приложения. Если вас интересует только абсолютное время (например, если вы хотите отображать только «создано 10 минут назад»), то подойдет любой вариант.
Иногда смещение имеет значение, например, если вы хотите показать что-то вроде «Сотрудник вошел в систему в 8 утра», это должно быть в соответствии с местным временем этого сотрудника. Учитывая, что сотрудник находится в +01:00, а вы в -05:00, там будет либо написано «Сотрудник вошел в систему в 9 утра», если преобразовано в UTC и отображено в формате UTC, либо, если отображается как ваше местное время, «Сотрудник вошел в систему в 14:00».
Есть также даты, которые не связаны со смещением часового пояса. Их называют простые финики. Хорошим примером может служить день рождения, поскольку отображение 2024-04-14T00:00:00.000Z как местного времени в -01:00 приведет к неверной дате 2024-04-13.
Важно: обычную дату нельзя сопоставить с абсолютным временем, не зная смещения часового пояса. В примере входа в систему сотрудника, если вы хотите отобразить только это сообщение, вы можете использовать простую дату (созданную в местном часовом поясе сотрудника), но было бы неправильно использовать ее для других случаев использования, таких как «Сотрудник вошел в систему 3 часа назад», поскольку вы не можете знать абсолютный момент времени. Многие библиотеки дат с радостью анализируют простую дату как локальную дату, что, как правило, неверно, но будет замечено только тогда, когда ваше приложение использует кто-то из другого часового пояса.
Заключение: По сути, каждый раз, когда вы программно фиксируете дату, это должно быть абсолютное время. Имеет ли значение смещение и как оно обрабатывается, зависит от варианта использования.
Вы преобразовали первую дату в строку, и это произошло в вашем местном часовом поясе. Когда вы регистрируете
bиc, вы регистрируете их в представлении по умолчанию, то есть в формате UTC («Z» в конце строки). Времена уже близки; первый явно включает в себя смещение часового пояса.