Браузеры могут отличаться, и вы также должны помнить, что не следует доверять какой-либо информации, сгенерированной клиентом, при этом приведенное ниже утверждение работает для меня (Google Chrome v24 в Mac OS X 10.8.2)
var utcDate = new Date(new Date().getTime());
edit: "Чем это отличается от new Date()
?" смотрите здесь: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date
- Если аргументы не предоставлены, конструктор создает объект JavaScript Date для текущей даты и времени в соответствии с настройками системы.
- Примечание. Если Date вызывается как конструктор с более чем одним аргументом, указанные аргументы представляют собой местное время. Если требуется UTC, используйте новую дату ( Date.UTC (...) ) с теми же аргументами. (примечание: Date.UTC () возвращает количество миллисекунд с 1970-01-01 00:00:00 UTC)
Добавление 60000 * Date.getTimezoneOffset (), как указано в предыдущих ответах, неверно. Во-первых, вы должны думать обо всех датах / временах как о времени UTC с модификатором часового пояса для целей отображения.
Опять же, браузеры могут отличаться, однако Date.getTime () возвращает количество миллисекунд с 1970-01-01 UTC / GMT. Если вы создадите новую дату, используя этот номер, как я делаю выше, это будет UTC / GMT. Однако, если вы отобразите его, вызвав .toString (), он окажется в вашем местном часовом поясе, потому что .toString () использует ваш местный часовой пояс, а не часовой пояс объекта Date, для которого он вызывается.
Я также обнаружил, что если вы вызываете .getTimezoneOffset () для даты, она возвращает ваш местный часовой пояс, а не часовой пояс объекта даты, для которого вы его вызвали (однако я не могу проверить, чтобы это было стандартным).
В моем браузере добавление 60000 * Date.getTimezoneOffset () создает DateTime, не UTC . Однако, когда отображается в моем браузере (например: .toString ()), он отображает DateTime в моем местном часовом поясе, который будет правильным временем UTC, если информация о часовом поясе игнорируется.