Время эпохи (Галочки с 1970) - Mac по сравнению с Windows

У меня есть некоторые веб-сервисы 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. Обе машины установлены на тот же часовой пояс.

5
задан Stu Thompson 14 April 2011 в 16:22
поделиться

3 ответа

Мое предположение будет различия на платформе, касающихся, когда заканчивается и начинается DST. ТЕХНИЧЕСКИЕ ТЕХДАТОРЫЕ ДЛЯ ДЕЙТЕЖНЫХ ЛЕТ ПРИНЯТЬ ПРАВА?

2
ответ дан 14 December 2019 в 13:37
поделиться

Это звучит очень, как один из них дает вам галочки с момента эпохи, а другой дает вам миллисекунды с 1970 года 1 января в вашем местном часовом поясе ... Или они интерпретируют данные таким образом. Все ли «неправильные» даты летом, случайно? (Редактировать: Теперь я видел ваше редактирование, я вижу, вы думаете по теми же линиям.)

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

, если это возможно, было бы хорошей идеей оказывать мгновенные мгновения с полуночи 1 января 1970 года UTC . Большинство платформ дают достаточно простой способ обращения с этим. В .NET, если вы используете dateTimeOffset вместо dateTime . Вы должны избегать, по крайней мере, некоторые из этих проблем. (В будущем, конечно, правильное решение будет использовать время Noda . Но еще нет.)

Редактировать: хорошо, теперь вы предоставили данные образца, это не похоже на На самом деле есть какая-то несоответствие в мгновение . Очень возможно, что разные платформы будут иметь разные взгляды на историческую информацию с часовым поясом, безусловно, - некоторые, возможно, имеют постоянное правило, которое они предполагают, будут были правильными, и будет БЫТЬ ПРАВИЛЬНО, другие будут знать о различных изменения вовлечены. Я бы сказал Большинство платформ, чтобы принять во внимание исторические изменения в эти дни, по общему признанию ...

на iPhone, по крайней мере, я ожидаю, что вы сможете написать код, чтобы узнать часовой пояс Переходы, а затем сравните это с помощью чего .NET дает через TimezoneInfo .

Каково ваше приложение на самом деле делает с этой информацией? Вы заинтересованы в этом как мгновение во времени (который можно рассматривать в разных часовых поясах) или просто местное время?

4
ответ дан 14 December 2019 в 13:37
поделиться
1-

Могу поспорить, что это часовая тона, где ваш Mac преобразует временные метки в ваш локальный часовой пояс, что для некоторого времени находится в летнее время сэкономия (DST), а некоторые не могут, вызывая разницу с двумя часами по сравнению с UTC, что не имеет Дт.

0
ответ дан 14 December 2019 в 13:37
поделиться
Другие вопросы по тегам:

Похожие вопросы: