Поведение iOS Safari getTime() DST

я столкнулся со странным поведением сафари iOS 8.2 при преобразовании строк даты и времени в временные метки unix ms во время перехода на летнее время. Допустим, у нас есть js-код

function date2unix(dates){
  var len = dates.length;
  var result = [], arr;
  while(len--) {
    arr = dates[len].split(/[- :]/);
    result[len]= (new Date(arr[0], arr[1]-1, arr[2], arr[3],arr[4],arr[5]).getTime());
  }
  return result;
}

var dates =
["2015-03-29 00:00:00","2015-03-29 00:15:00","2015-03-29 00:30:00","2015-03-29 00:45:00","2015-03-29 01:00:00","2015-03-29 01:15:00","2015-03-29 01:30:00","2015-03-29 01:45:00","2015-03-29 03:00:00","2015-03-29 03:15:00","2015-03-29 03:30:00","2015-03-29 03:45:00"];

alert(date2unix(dates))

iOS 8.2 Safari дает неоднозначные значения (1-й == 5-й, 2-й == 6-й, ...), в то время как хром 41.0.2272.101 ведет себя правильно. Обратите внимание, что оспариваемый 2-й час был опущен в датах массива. Может ли кто-нибудь помочь мне с поиском обходного пути, пожалуйста?

Попробуйте: http://jsfiddle.net/q6vd0fos/

С уважением


javascript datetime dst gettime
person TauWich    schedule 02.04.2015    source источник
comment
desired output is 1427583600000, 1427584500000, 1427585400000, 1427586300000, 1427587200000, 1427588100000, 1427589000000, 1427589900000, 1427590800000, 1427591700000, 1427592600000, 1427593500000 without any duplicity, iOS gives 1427583600000, 1427584500000, 1427585400000, 1427586300000, 1427583600000, 1427584500000, 1427585400000, 1427586300000, 1427590800000, 1427591700000, 1427592600000, 1427593500000   -  person TauWich    schedule 03.04.2015
comment
К сведению: нельзя проверить эти точные результаты, не зная настроек часового пояса, на которые настроен ваш компьютер.   -  person Matt Johnson-Pint    schedule 05.04.2015

Ответы (1)


arrow_upward
0
arrow_downward

Время, о котором идет речь, недопустимо для вашего часового пояса, поскольку оно попадает в разрыв, созданный весенним переходом на летнее время.

Когда вы делаете это в JavaScript, реализация не определена. Каждый браузер будет делать что-то свое. Некоторые браузеры будут пропускать вперед, некоторые будут пропускать назад. Вы мало что можете с этим поделать, потому что это неопределенное поведение.

Другой способ думать об этом состоит в том, что JavaScript, вероятно, должен возвращать undefined для этих значений. Единственная причина, по которой он не может этого сделать, заключается в том, что вы не можете получить undefined в результате вызова конструктора допустимого объекта. Но логически значение не определено.

На приведенном ниже графике из вики тега DST показан разрыв. Эта конкретная диаграмма относится к часовому поясу Тихоокеанского региона США, но та же идея применима ко всем зонам, в которых используется летнее время (но даты и время могут различаться). Значения местного времени на этом графике, начиная с 2:00 и заканчивая 3:00, не определены. Например, если вы указали 2:30 в этот день, некоторые реализации дадут вам 1:30, а некоторые — 3:30.

Spring Forward DST Transition

Правильнее всего не пытаться преобразовать недопустимое время.

См. также: Мусор на входе, мусор на выходе.

person Matt Johnson-Pint    schedule 05.04.2015