午後には、MVCとEXTJの日付形式を変換する際に問題が発生しました。 .NETサーバー側からDateTimeオブジェクトをシリアル化した結果は、 '/date（1335258540000）/'などの文字列形式です。
整数1335258540000は、実際には1970年1月1日からこの年代の間のミリ秒間隔です。 JavaScriptを介して、評価関数を使用して、次のように、この日付文字列をタイムゾーンのある日付オブジェクトに変換します
var date = eval（ 'new' + eval（ '/date（1335258540000）/'）。ソース）を使用してJSオブジェクトを取得します
アラート（日付）を通じてはっきりと確認してください。
火曜日4月24日17:09:00 UTC+0800 2012
上記は、C＃JSONの日付をシリアル化することにより自動的に取得される文字列です。たとえば、C＃を介してこの番号を取得する関数を記述することもできます
public long millitimestamp（datetime thedate）{datetime d1 = new DateTime（1970、1、1）; DateTime d2 = thedate.touniversaltime（）; TimesPan TS = New TimesPan（D2.Ticks -D1.Ticks）; return（long）ts.totalmilliseconds; }上記の関数は、JSONシリアル化を使用して取得した文字列の整数と同じです。
ただし、クライアントからサーバー側に戻ると、日付に問題があります。 JavaScriptの日付オブジェクトをサーバー側に戻す方法は？
まず、JavaScriptの日付でgetTime（）を介してこの整数を取得し、サーバー上の整数を解析し、C＃DateTimeオブジェクトに「構築」します。アイデアはおそらくこのようなものですが、反対方向に戻ったときにいくつかのトラブルに遭遇しました。
Public DateTime Convertime（Long Milliontime）{Long Timetricks = new DateTime（1970、1、1）.Ticks + MillionTime * 10000;新しいDateTime（Timetricks）を返します。 }Convertimeを通じて得られた結果は、時間が8時間短く、たまたまサーバーのタイムゾーンであるEast Eighth Zone Timeであることがわかりました。つまり、8時間のナノ秒を追加する必要があります。
したがって、変換時間関数は変更され、正しい機能は次のとおりです。
Public DateTime Convertime（Long Milliontime）{Long Timetricks = new DateTime（1970、1、1）.Ticks + MillionTime * 10000 + TimeZone.CurrentTimeZone.getUtCoffset（datetime.now）.hours * 3600 *（long）100000000;新しいDateTime（Timetricks）を返します。 }JSとC＃の日付と日付の形式の変換の上記の簡単な例は、私があなたと共有するすべてのコンテンツです。参照を提供できることを願っています。wulin.comをもっとサポートできることを願っています。