Неправильное местное время в веб-обозревателе Android - PullRequest
0 голосов
/ 05 октября 2018

У нас есть приложение для Android, которое более или менее состоит только из веб-просмотра, отображающего веб-приложение.В какой-то момент мы хотим отобразить некоторую временную метку для пользователя и использовать следующий код

let dateString = new Date().toLocaleTimeString();

Проблема в том, что это всегда дает 12-часовое представление времени (то есть с AM / PM, например 3:15 PM).вместо 15:15), даже если мы настроим устройство на использование 24-часовых часов (и устройство соблюдает эту настройку, потому что мы видим правильное время в строке состояния).Мы также настроили устройство на использование немецкого языка и удалили настройки английского языка.Не повезло тоже.Используется локаль устройства, так как наше приложение отображается на правильном языке, но временные строки все еще неверны.

window.navigator.language  -> "de-AT"
new Date().toLocaleTimeString(); -> "6:10:13 PM"
new Date().toLocaleTimeString(window.navigator.language); -> "18:10:32"

На первый взгляд, последняя строка казалась возможным решением, но если язык, например, "en-US", он всегда будет возвращать 12-часовой формат, независимо от того, настроена ли ОС на использование 24-часового.часы или нет.

Мне известен этот вопрос, который как-то связан с этой проблемой, но ответы у нас не работают.

Используя различные виртуальные устройства, которые я обнаружил, он все еще корректно работает на chrome 58 (на API 26), но больше не работает на chrome 61 (на API 27).В настоящее время тестирование на бета-версии Chrome 70, проблема все еще сохраняется.

Также важно отметить, что он работает правильно в самом Chrome (то есть, если я отображаю метку времени на тестовом веб-сайте, он использует системные настройки), но происходит сбой только в веб-просмотре.

Наш текущий обходной путь - генерировать временные метки с помощью собственного приложения, но это выглядит довольно неуклюже.

ОБНОВЛЕНИЕ

Я знаю, что могу сделать некоторые вещи на стороне веб-приложения, такие как переопределение toLocaleTimeString (что на самом деле я уже сделал, чтобы получить правильный формат изродное приложение).

Мой вопрос больше о том, есть ли какое-либо известное измененное поведение (и, может быть, настройка для изменения) в нативном WebView, которое вызывает эту проблему, потому что это работает / работает какОчарование на устройствах с Chrome <= 58. </p>

Тем временем я подал вопрос с хромом, они смогли его воспроизвести.Возможно, это будет исправлено в одной из следующих версий ...

ОБНОВЛЕНИЕ 2

Эта проблема уже исправлена ​​на стороне Google и может быть развернута в будущемОбновить.В то же время я продолжу использовать текущее переопределение toLocaleTimeString(), которое возвращает к собственному приложению ...

Ответы [ 2 ]

0 голосов
/ 21 октября 2018

Переопределить Date.prototype.toLocaleTimeString

 let newDate = Date.prototype.toLocalString;
 Date.prototype.toLocalString = function(){
  let newString = newDate();
  //since the method fails for US-locale manupulate s as required when locale is US and system is set to show 24 hr 

  // if time ends with AM - remove AM
  // if time ends with PM - add 12 to hr and remove PM
  return newString;
}
0 голосов
/ 19 октября 2018

Пожалуйста, попробуйте переопределить функцию Date.prototype.toLocaleTimeString

let f = Date.prototype.toLocalString;

Date.prototype.toLocalString = function(){
  let s = f();
  //since the method fails for US-locale manupulate s as required when locale is US and system is set to show 24 hr 
  
  // if ends with AM - just delete "AM"
  // if ends with PM - add 12 to hr and delete "PM"
  return s;
}
--- пожалуйста, избегайте прямого изменения прототипа встроенных объектов JS - позвольте мне также отметить, что не рекомендуется играть со встроенным объектом JS, поскольку это может нарушить или прервать выполнение некоторыхвнешние библиотеки.Так что лучше создайте новый объект и измените прототип этого объекта - используйте прототип наследования.
...