У меня есть некоторые веб-сервисы C# тот возврат JSON. JavaScriptSerializer.NET возвращает даты во Время Эпохи (миллисекунды с 1970). На любой машине Windows веб-приложение обрабатывает миллисекунды назад в надлежащую дату без проблемы.
На моем Mac даты иногда выключены на 1 час. Не каждый раз. Только иногда. Это теперь происходит на фронтэнде iPhone, который я создаю также.
Я думал сначала, что потерял некоторую точность при делении миллисекунд на 1 000 для создания допустимого Objective C объект NSDate. Затем я протестировал создание даты в JavaScript на Firefox Mac с той же меткой времени и получил смещение того же 1 часа.
Какие-либо идеи?Спасибо...
Править: Я также заметил в Консоли в XCode, что созданная дата имела-4 или-5 рядом с ним. Я предполагаю, что это - смещение GMT. Они, кажется, варьируются независимые от того, смещается ли дата на 1 час. Таким образом, приблизительно-4 даты и приблизительно-5 дат корректны, и часть любого смещается.
Править: Использование в качестве примера:
console.log(new Date(-1173643200000));
возвраты Sun 23 октября 1932 0:00:00 GMT 4:00 (EST)
console.log(new Date(-1031515200000));
возвраты суббота 24 апреля 1937 23:00:00 GMT 5:00 (EST)
NSDate* date = [NSDate dateWithTimeIntervalSince1970:ticks / 1000];
-589320000000 =
1951-04-30 00:00:00 -0400
-1173643200000 =
1932-10-22 23:00:00 -0500
(Эти возвраты исправляют в Консоли Firebug, неправильно в Консоли XCode),
-1303416000000 =
1928-09-12 00:00:00 -0400
-1492545600000 =
1922-09-15 00:00:00 -0400
-1263668400000 =
1929-12-16 00:00:00 -0500
-1252094400000 =
1930-04-29 00:00:00 -0400
-1046458800000 =
1936-11-03 00:00:00 -0500
-1298746800000 =
1928-11-05 00:00:00 -0500
-1031515200000 =
1937-04-24 23:00:00 -0500
(Возвраты неправильно и в Консоли Консоли и в XCode Firebug)
-910465200000 =
1941-02-24 00:00:00 -0500
-1152648000000 =
1933-06-23 00:00:00 -0400
-1109793600000 =
1934-10-31 23:00:00 -0500
Действительно ли возможно, что Microsoft/Mozilla/Apple имеет конфликтующее определение правил когда Летнее время, запущенное тогда?
Править: Firefox Mac и Windows Firefox получают различные результаты для-1031515200000. Обе машины установлены на тот же часовой пояс.
Мое предположение будет различия на платформе, касающихся, когда заканчивается и начинается DST. ТЕХНИЧЕСКИЕ ТЕХДАТОРЫЕ ДЛЯ ДЕЙТЕЖНЫХ ЛЕТ ПРИНЯТЬ ПРАВА?
Это звучит очень, как один из них дает вам галочки с момента эпохи, а другой дает вам миллисекунды с 1970 года 1 января в вашем местном часовом поясе ... Или они интерпретируют данные таким образом. Все ли «неправильные» даты летом, случайно? (Редактировать: Теперь я видел ваше редактирование, я вижу, вы думаете по теми же линиям.)
Не могли бы вы дать нам некоторые значения образца, а код, который вы используете в разных местах? Вы уверены, что сама ценность неверна, и это не просто проблема отображения?
, если это возможно, было бы хорошей идеей оказывать мгновенные мгновения с полуночи 1 января 1970 года UTC . Большинство платформ дают достаточно простой способ обращения с этим. В .NET, если вы используете dateTimeOffset
вместо dateTime
. Вы должны избегать, по крайней мере, некоторые из этих проблем. (В будущем, конечно, правильное решение будет использовать время Noda . Но еще нет.)
Редактировать: хорошо, теперь вы предоставили данные образца, это не похоже на На самом деле есть какая-то несоответствие в мгновение . Очень возможно, что разные платформы будут иметь разные взгляды на историческую информацию с часовым поясом, безусловно, - некоторые, возможно, имеют постоянное правило, которое они предполагают, будут были правильными, и будет БЫТЬ ПРАВИЛЬНО, другие будут знать о различных изменения вовлечены. Я бы сказал Большинство платформ, чтобы принять во внимание исторические изменения в эти дни, по общему признанию ...
на iPhone, по крайней мере, я ожидаю, что вы сможете написать код, чтобы узнать часовой пояс Переходы, а затем сравните это с помощью чего .NET дает через TimezoneInfo
.
Каково ваше приложение на самом деле делает с этой информацией? Вы заинтересованы в этом как мгновение во времени (который можно рассматривать в разных часовых поясах) или просто местное время?
Могу поспорить, что это часовая тона, где ваш Mac преобразует временные метки в ваш локальный часовой пояс, что для некоторого времени находится в летнее время сэкономия (DST), а некоторые не могут, вызывая разницу с двумя часами по сравнению с UTC, что не имеет Дт.