5

JSON を返す C# Web サービスがいくつかあります。.NET JavaScriptSerializer は、エポック時間 (1970 年からのミリ秒) で日付を返します。どの Windows マシンでも、Web ベースのアプリケーションはミリ秒を処理して適切な日付に問題なく戻します。

私の Mac では、日付が 1 時間ずれることがあります。毎回ではありません。たまにしか。これは、私が構築している iPhone フロント エンドでも発生しています。

最初は、有効な Objective-C NSDate オブジェクトを作成するためにミリ秒を 1000 で割ったときに、精度がいくらか失われたと思いました。次に、同じタイムスタンプを使用して Mac Firefox の JavaScript で日付の作成をテストし、同じ 1 時間のオフセットを得ました。

何か案は?ありがとう...

編集: XCode のコンソールで、作成された日付の横に -4 または -5 があることにも気付きました。それはGMTオフセットだと思います。日付が 1 時間オフセットされているかどうかに関係なく、それらは異なるようです。したがって、いくつかの -4 日付といくつかの -5 日付は正しく、どちらかの日付のいくつかはずれています。

編集:使用例:

console.log(new Date(-1173643200000));

1932 年 10 月 23 日日曜日 00:00:00 GMT-0400 (EST) を返します

console.log(new Date(-1031515200000));

1937 年 4 月 24 日土曜日 23:00:00 GMT-0500 (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   

(Firebug コンソールと XCode コンソールの両方で間違った値を返します)

-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 が、当時の夏時間の開始時期を定義するルールが競合している可能性はありますか?

編集: Mac Firefox と Windows Firefox では、-1031515200000 の結果が異なります。両方のマシンが同じタイムゾーンに設定されています。

4

3 に答える 3

4

そのうちの 1 つはエポック以降のティックを提供しており、もう 1 つは 1970 年 1 月 1 日からのミリ秒をローカル タイム ゾーンで提供しているように聞こえます...または、データをそのように解釈しています。ひょっとして、夏のすべての「間違った」日付はありますか? (編集: 今、私はあなたの編集を見ました。あなたが同じ方針に沿って考えていることがわかります。)

いくつかのサンプル値と、さまざまな場所で使用しているコードを教えてください。表示だけの問題ではなく、値自体が間違っていると確信していますか?

可能であれば、1970 年 1 月 1 日UTCの真夜中以降のインスタントを提供することをお勧めします。ほとんどのプラットフォームは、それを処理するかなり簡単な方法を提供します。.NET では、DateTimeOffset代わりにを使用する場合DateTime、少なくともこれらの問題のいくつかを回避する必要があります。(もちろん、将来的には、適切な解決策はNoda Timeを使用することになります。ただし、まだではありません。)

編集:さて、サンプル データを提供しました。返された瞬間に実際に矛盾があるようには見えません。異なるのは、現地時間への変換です。確かに、異なるプラットフォームが過去のタイム ゾーン情報の異なるビューを持っている可能性は非常に高いです。確かに、あるものは正しいと仮定し、永遠に正しいと仮定する恒久的なルールを持っているだけかもしれませんし、他のものは関連するさまざまな変更について知っているでしょう. 確かに、最近ではほとんどのプラットフォームが歴史的な変化を考慮に入れていると思います...

少なくとも iPhone では、コードを記述してタイム ゾーンの遷移を検出し、それを .NET が提供するものと比較できることを期待していますTimeZoneInfo

あなたのアプリケーションは、この情報を使って実際に何をしていますか? 時間の瞬間 (さまざまなタイム ゾーンで見なすことができます) またはローカル タイムとして関心がありますか?

于 2010-01-11T20:47:43.730 に答える
2

私の推測では、DST の終了時期と開始時期に関するプラットフォームの違いでしょう。現在の年のタイムスタンプは正しいですか?

于 2010-01-12T18:45:02.303 に答える
0

Mac がタイムスタンプをローカル タイムゾーンに変換するタイムゾーンの問題だと思います。一部のタイムスタンプは夏時間 (DST) であり、一部はそうではなく、DST がない UTC と比較して 1 時間の時差が生じます。 .

于 2010-01-11T20:50:41.910 に答える