エラー調査のために Kudu 周りを調べていたら、Wiki に Web Apps のタイムゾーン設定が追加されていたのに気が付いたので、実際に設定して試してみました。
Kudu の Wiki はちょいちょい更新されているので、ちゃんと確認しておかないといけないですね。
Configurable settings · projectkudu/kudu Wiki · GitHub
基本的に Azure のサービスは UTC がデフォルトの設定になっていて、Cloud Services では Startup Task などを使ったタイムゾーンの変更が非推奨となっていました。
But I would strongly advice against it. The Fabric Controller maintains operating system time synchronization for the system when roles are first booted. If you utilize administrative access startup scripts to change the localization settings (including local server time), but it is not recommended you do so. Doing so will introduce instability and the fabric controller may determine your role is out of sync. You will likely end up cycling your roles as fabric attempts to bring them to goal state in such a case. A better strategy is to write your applications to be aware that they actually run with UTC and default US CultureInfo settings.
http://blogs.msdn.com/b/cie/archive/2013/07/29/manage-timezone-for-applications-on-windows-azure.aspx
Azure 界の抱かれたい男 No.1 ことぶちぞうさんも、止めといた方がいいと言ってます。
やめといたほうが無難
— こすもす.えび (@kosmosebi) 2015年9月8日
しかし、Web Apps だけは WEBSITE_TIME_ZONE というキーを追加することで、任意のタイムゾーンで動作させることが出来るようになったみたいです。
WEBSITE_TIME_ZONE に設定する値は、レジストリや TimeZoneInfo から取得出来る文字列です。
日本時間は JST ではなくて Tokyo Standard Time なので、少し注意が必要な感じです。
確認のために DateTime.Now と UtcNow を出力するだけのページを用意しました。
デフォルトは UTC なので、両方とも同じ時間となっています。これが Azure では普通です。
ここでポータルから WEBSITE_TIME_ZONE = Tokyo Standard Time という設定を追加してみます。
設定を保存後、ページを読み込みなおすと DateTime.Now が日本時間に変化していました。
App Service Plan 単位でタイムゾーンが設定されるのかと思ったので、同一ホスティングプラン上で動作しているアプリケーションでも試してみました。
マシン名を表示させているので、同一マシンで動作していることが分かると思います。予想に反してサイト単位でタイムゾーンが設定可能になっているようです。
Kudu のソースコードに出てこないので、カスタム IIS モジュールで変更するようになっているのだと思いますが、特定のプロセスだけタイムゾーンを変更可能なのか、正直よくわかっていません。謎技術です。
古いアプリのマイグレーション用途ぐらいで、乱用はしない方がいい気がします。公式ドキュメントの FAQ にも記載されるようになっているので、普通に使っていっても良いと思います（実際使ってます
何だかんだでタイムゾーンを設定した方が楽なことが多いです。確認した感じでは Consumption での Azure Functions でも問題なく動作しているので、特に不安もないと思っています。
