Я пишу некоторый JavaScript для одной из наших таблиц базы данных для функций CRUD, и одно из полей идентификаторов, используемых для идентификации элемента данных, - это дата.При извлечении этих данных с использованием AJAX они предоставляются в полном формате данных JavaScript: Thu Apr 25 2019 00:00:00 GMT+0100 (British Summer Time).
Это вызывает проблемы, поскольку при отправке Kendo UI меняет его на UTC, и в этом случае день меняется на 24 апреля, то есть наш внутренний код не может найти запись.
Я попытался это исправить, изменив это поле, когда оно вводится с помощью .toLocalDateString.Это исправило мою проблему, так как, кажется, просто отрубает информацию о часовом поясе и просто дает мне DD/MM/YYYY, которую принимает бэкэнд.
Мой вопрос: будет ли это иметь ожидаемый эффект (игнорировать часовой пояс и просто дать мне дату), если программа используется, скажем, в восточной части США.
Поскольку я нахожусь в Британиии наш часовой пояс в настоящее время британское летнее время, то есть часовой пояс, в котором находились исходные данные, это работает только с тех пор, как я нахожусь в BST?Если бы я был в EST, который отстает на 5 или 6 часов, .toLocaleDateString заставил бы день вернуться назад 1?
Я посмотрел в документации и все, что там написано, «Использование локальных соглашений»,и смысл этого мне неясен.
Редактировать: Я получаю Mon May 13 2019 00:00:00 GMT+0100 (British Summer Time) от запроса AJAX.Когда я отправляю это обратно, я строчу данные, и они приводятся к следующему: "2019-05-12T23:00:00.000Z", который находится в UTC, вызывая проблему.