7

仕様によれば、イタリアにあるサーバーで実行する必要があり、クライアントはイタリア人のみであるという事実を考慮して、アプリケーションを設計しました。

約 1 か月前、上司はすべてを Azure に移行することにしました。

すべてが順調に進みました。唯一の問題は、タイム サーバーが UTC であることです。

解決策は次のとおりです。

シンプルな

起動スクリプトをサーバー時間に変更します ( http://netindonesia.net/blogs/wely/archive/2011/06/26/setting-timezone-in-windows-azure.aspx )

B) より手間がかかる

アプリケーションが UTC を使用し、現地時間に正しく変換された時刻を表示するように変更します。

解決策 A を選択する場合、サーバーが別のタイムゾーンでセットアップされているという事実が、何らかの形で Azure との競合を引き起こす可能性があるということです。

これは本当です？

4

3 に答える 3

13

MSサポートに問い合わせました。

これは応答です：

スタートアップ タスクを使用して Azure Virtual Machines のサーバー時刻を変更することはお勧めしません。代わりに、コードで TimeZoneInfo.ConvertTimeFromUTCTime などのメソッドを使用する必要があります。

したがって、サーバーのタイムゾーンは変更しません。サポートからの応答を待っていると、SqlServer 2008 の DateTimeOffset データ型が完璧であることがわかりました。

http://blogs.msdn.com/b/davidrickard/archive/2012/04/07/system-datetime-good-practices-and-common-pitfalls.aspx

于 2011-06-28T16:28:52.657 に答える
4

数年前、クライアントとサーバーの両方で UTC を使用して日付を処理するようにすべてのアプリの設計を開始し、それ以来振り返っていません。

于 2011-06-29T11:38:09.987 に答える
2

クライアント側とサーバー側の DateTime.Now と DateTime.Today には 2 つの問題があります。クライアントから Azure に DateTime オブジェクトを渡すと、その Kind は Local に等しくなり、タイム ゾーン情報が含まれます。(2011 年 6 月 10 日、午前 12 時 30 分～7 日)

ただし、データベースに保存すると、地域情報は失われます。その後、データベースからこのフィールドを読み取ると、Utc 地域で DateTime が作成されます (2011 年 6 月 10 日午前 0 時 30 分)。

最終的に、クライアントは日時を誤って読み取ります。

クライアント側でこの問題を解決するには、いくつかのオプションがあります。

1) メソッド パラメータとデータベースで DateTime を DateTimeOffset に変換します。これにより、ローカル リージョン (つまり PST) がデータベースに保存されることが保証されます。

2）DateTime.SpecifyKind（dateTime、DateTimeKind.Unspecified）を使用します-このようにDateTimeの種類は指定されておらず、その後そのままデータベースに保存されます。

var timeNow = DateTime.SpecifyKind(DateTime.Now, DateTimeKind.Unspecified);
serviceClient.SaveTime(timeNow);
var dateTime = serviceClient.GetTime();

サーバー側で DateTime.Now を呼び出す場合は注意してください。DateTime.UtcNow を使用することをお勧めします。この時間は、ビジネス データには使用しないでください。理想的には、コードをリファクタリングし、クライアントから DateTime または DateTimeOffset を渡す必要があります。

于 2011-06-29T11:09:25.790 に答える