«getDate не является функцией» после добавления часового пояса - PullRequest
Новая
       3

«getDate не является функцией» после добавления часового пояса

3 голосов
/ 11 апреля 2019

Я показываю дату и время в реальном времени, но получаю сообщение об ошибке getDate is not a function.

Я получаю эту ошибку, потому что я добавил часовой пояс, как это 

var x = new Date().toLocaleString("en-US", {timeZone: "America/New_York"});

Не могли бы вы помочь мне в этом вопросе? 

function calculateUSATime() {
  var refresh = 1000; // Refresh rate in milli seconds
  mytime = setTimeout('currentUSATime()', refresh)
}


function currentUSATime() {
  var x = new Date().toLocaleString("en-US", {
    timeZone: "America/New_York"
  });
  var date = x.getDate();
  var month = x.getMonth(); //Be careful! January is 0 not 1
  var year = x.getFullYear();
  document.getElementById('ct').innerHTML = date;
  calculateUSATime();
}
<body onload=currentUSATime();>
  <span id='ct'></span>

</body>

Ответы [ 2 ]

5 голосов
/ 11 апреля 2019

toLocaleString вернет String.Вы можете передать его снова в конструктор даты, чтобы получить экземпляр Date.Согласно MDN

Метод toLocaleString() возвращает строку с чувствительным к языку представлением этой даты 

var days = ['Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday'];


function calculateUSATime() {
  var refresh = 1000; // Refresh rate in milli seconds
  mytime = setTimeout('currentUSATime()', refresh)
}


function currentUSATime() {
  let str = new Date().toLocaleString("en-US", {
    timeZone: "America/New_York"
  })
  var x = new Date(str);
  var date = x.getDate();
  var month = x.getMonth(); //Be careful! January is 0 not 1
  var year = x.getFullYear();
  document.getElementById('ct').innerHTML = days[x.getDay()]+ ' ' + x.toLocaleString();
  calculateUSATime();
}
<body onload=currentUSATime();>
  <span id='ct'></span>

</body>

Еще одна вещь, которую вы можете улучшить, это удалить calculateUSATime и использовать setTimeout внутри currentUSATime. 

function currentUSATime() {
  let str = new Date().toLocaleString("en-US", {
    timeZone: "America/New_York"
  })
  var x = new Date(str);
  var date = x.getDate();
  var month = x.getMonth(); //Be careful! January is 0 not 1
  var year = x.getFullYear();
  document.getElementById('ct').innerHTML = x;
  
  var refresh = 1000; // Refresh rate in milli seconds
  mytime = setTimeout(currentUSATime, refresh)
  
}
<body onload="currentUSATime();">
  <span id='ct'></span>

</body>
2 голосов
/ 11 апреля 2019

Как уже упоминалось, toLocaleString возвращает string, и, следовательно, вы не можете рассматривать его как Date объект.Так как вы все равно хотите отобразить ее как строку, тогда правильный подход - просто передать все аргументов, которые вам нужны, чтобы получить строку в нужном формате.

Дляпример: 

var s = new Date().toLocaleString(undefined, { 
    timeZone: 'America/New_York',
    weekday: 'long',
    year: 'numeric',
    month: 'numeric',
    day: 'numeric',
    hour: 'numeric',
    minute: 'numeric',
    second: 'numeric'
})

Это дает текущее время в America/New_York (восточное время США), используя языковой стандарт пользователя для форматирования (undefined по умолчанию - языковой стандарт пользователя), и указывает, что полное имядолжен быть указан день недели, а также числовой формат даты и времени.

Пример выходных данных в зависимости от локали пользователя: 

en-US    "Thursday, 4/11/2019, 1:13:14 PM"
en-GB    "Thursday, 11/04/2019, 13:13:14"
fr-FR    "jeudi 11/04/2019 à 13:13:14"
zh-CN    "2019年4月11日星期四 下午1:13:14"

Все параметры можно прочитать в документация toLocaleString .

В другом ответе также предлагалось, чтобы вы могли взять вывод toLocaleString и проанализировать его с помощью конструктора объекта Date.Такой подход не рекомендуется по следующим причинам:

  • Спецификация ECMAScript не требует, чтобы эти строки могли обрабатываться синтаксическим анализатором Date.Требуется только разбор строк, соответствующих ISO8601, таких как "2019-04-11T13:13:14".Все остальное (даже если это выглядит просто как "4/11/2019, 1:13:14 PM") зависит от реализации.Другими словами, не все браузеры согласятся с тем, как анализировать эти строки, а некоторые откажутся, предоставив Invalid Date.

  • Анализатор объекта Date всегда будет использовать пользователятекущая локальПоэтому, если вы в коде en-US жестко закодировали языковой стандарт для *1040*, а затем проанализировали его в Великобритании, вы ошибочно переключили бы компоненты месяца и дня.11 апреля будет рассматриваться как 4 ноября.

  • Когда вы анализируете строку, которая выглядит как местное время, с объектом Date, он будет справедливо предполагать, что это локальное время пользователя.зона.Есть последствия этого.Учтите, что вы можете передавать дату и время, которые действительны в America/New_York, но недействительны в местном часовом поясе пользователя.Например, 31 марта 2019 года в 1:30 утра действителен в США, но будет недействительным в Великобритании, потому что он попадает в разрыв с переходной экономикой на летнее время (часы в Великобритании повысились с 00:59 до 02:00,пропуская этот час).В этом случае поведение не определено.Вы можете получить Invalid Date или 00:30 или 02:30, но не получите 01: 30.

  • Если вы реконструировали Date объектЕсли часовой пояс пользователя отличается от указанного, вы создаете совершенно другой момент времени.Если вы затем передадите этот объект Date во что-то другое, вы не сможете понять, что вы имели в виду Восточное время США.В конечном итоге, Date объекты не отслеживают даты, а хранят метку времени Unix, которая строго связана с UTC.Действительно, имя Date сбивает с толку и неуместно (ИМХО).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.

Нет похожих вопросов

...