Azureへデプロイ後に陥るトラブルのNo.1は時間関係（UTC）だと思う
2017.01.17:更新しました
AzureのWebAppsでは日本時間（JST）ではなく、協定世界時間 (UTC) が使用されます。
開発段階は気づきにくいのですが、Azure環境へデプロイした後、「あれ、時間がおかしい」と慌てふためきます。
ポイントとしては３箇所に注意が必要です。
１．WebApps上での時間表示
普通に、DateTime.Now() とかにすると、協定世界時間 (UTC)で表示されます。
日本時間は協定世界時間より 9時間速くなっています。(+9H)
参考：情報通信研究機構 http://www.nict.go.jp/JST/JST.html
何も考えずに、簡単に書くと下記でOKです。
DateTime.UtcNow.AddHours(9)
ただ、日本以外で使用する可能性があるならば、きちんとローカル時間に変換する必要はあります。
２．SQL Serverの時間
Web Appsだけ時間をローカル時間に表示しても、データベースも対応していないと意味が無いです。
ただ、SQLの場合タイムゾーンを認識する型は「datetimeoffset」となり、通常の「datetime」型ではUTCなのかJSTなのか判断が出来ません。
よって、Azureで使用する時間は基本的にUTCで登録するのが望ましいと思います。
単純に、ここのカラムはJSTで別のカラムはUTCで・・・となるのが面倒だからなんですが。
SQLサーバーでUTC時間を取得するには、下記のSELECT文で可能です。
SELECT GETUTCDATE()
取得時にDateAdd等で+9してあげると、日本時間にはなります。
これも、日本で使用するだけというのが前提にはなります。
３．カルチャの指定
標準の状態だと、String.Format()関数なんかで表示する時間であったり、単価であったりが英語表示になってしまいます。
Azureでは基本として「en-US」になっている為です。
これは、Web.config内のsystem.webセクションに追加してあげればOKです。
<globalization uiCulture="auto" culture="auto" />
ちなみに、下記のようにする事で日本語固定に出来ます。
<globalization uiCulture="ja" culture="ja-JP" />
autoにする事でブラウザーの言語設定から値を判断してくれるので、敢えて日本語固定にするのはあまり意味は無いと思いますが・・・。
最後に
比較的Azureは癖が少ないと思うのですが、時間周りが一番陥りやすい罠かなと思います。
知らないでローカル環境で作ってしまうと、デプロイ後に「時間が違う」となって、時間周りの大修正が始まりそう。現に僕がそうなんですけどね。
それでは！