Как работает метод getTime у объекта Date в JavaScript

Что проверяют

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

Как отвечать

• что возвращает: getTime() отдаёт число миллисекунд от 1970-01-01T00:00:00Z. Для new Date('2023-01-01T00:00:00Z') это 1672531200000, и результат одинаков в любом часовом поясе;
• синонимы: valueOf() возвращает то же, поэтому работают +date и dateB - dateA. Текущий момент без создания объекта даёт Date.now();
• некорректная дата: new Date('abc').getTime() вернёт NaN, отсюда надёжная проверка валидности Number.isNaN(d.getTime());
• секунды и миллисекунды: бэкенды часто отдают Unix-время в секундах, значит перед new Date(ts) его умножают на 1000, а при отправке делят и округляют через Math.floor.

Теперь про пояса, ради них вопрос и задают. Строка только с датой, '2023-01-01', разбирается как UTC. Строка с датой и временем без смещения, '2023-01-01T00:00', разбирается как местное время, поэтому их getTime() отличается на смещение пояса пользователя. Конструктор с числами new Date(2023, 0, 1) тоже местный, и месяц в нём считается с нуля.

Даты сравнивают по таймстемпам: a.getTime() === b.getTime(), потому что a === b сравнивает ссылки на объекты. Для замера длительности лучше performance.now(): он монотонный и не прыгает при переводе системных часов.

Где спотыкаются

Говорят, что getTime() «переводит время в UTC». Переводить нечего: таймстемп вообще не содержит пояса, от пояса зависят методы вроде getHours() и toString().

Прибавляют 24 * 60 * 60 * 1000, чтобы получить «завтра». В день перехода на летнее время это не следующая местная полночь, для календарной арифметики используйте setDate(d.getDate() + 1) или библиотеку дат.

Сравнивают объекты Date через === или == и получают false для одинаковых моментов. Операторы < и > при этом работают, потому что приводят объекты к числу.