TimeZoneInfo の取得方法を統一する

[b-wind]

その機能リクエストは何らかの問題に関連しますか / Is your feature request related to a problem?

LogFile に記録する TimeZone はJSTに固定されている。
この為 JST を表すTimeZoneInfoが必要だが、 TimeZoneInfo.FindSystemTimeZoneById で取得する形式となっている。

該当処理

cocoa/Covid19Radar/Covid19Radar/Common/Utils.cs

Lines 37 to 60 in 99712d4

	private static TimeZoneInfo JstTimeZoneInfo()
	{
	// iOS/Android/Unix
	try
	{
	return TimeZoneInfo.FindSystemTimeZoneById("Asia/Tokyo");
	}
	catch (TimeZoneNotFoundException)
	{
	// Not iOS/Android/Unix
	}
	// Windows
	try
	{
	return TimeZoneInfo.FindSystemTimeZoneById("Tokyo Standard Time");
	}
	catch (TimeZoneNotFoundException)
	{
	// Not Windows
	}
	// Emergency fallback
	return TimeZoneInfo.CreateCustomTimeZone("JST", new TimeSpan(9, 0, 0), "(GMT+09:00) JST", "JST");

呼び出し元

cocoa/Covid19Radar/Covid19Radar/Services/Logs/LoggerService.cs

Line 136 in 2a72949

var jstNow = Utils.JstNow();

（2021/12/11 追記） #578 に関連して

TimeSpam での演算はやめよう。

cocoa/Covid19Radar/Covid19Radar/Model/TermsUpdateInfoModel.cs

Lines 31 to 32 in 360150a

	public DateTime UpdateDateTimeUtc
	=> DateTime.SpecifyKind(UpdateDateTimeJst - TIME_DIFFERENCIAL_JST_UTC, DateTimeKind.Utc);

解決策についてお書きください / Describe the solution you'd like

Issue #523 で検討した手法に統一する。

あなたが考える代替案についてご説明ください / Describe alternatives you've considered

動いて居るので変えない。

ただし、同様の処理をバラバラの方法で行う事になる。

その他 / Additional context

個人的にはログに記録する日時もUTCにしたいところだけれど、強い要望では無い。

---

Internal IDs:

• NFR 5077

[keiji]

人間が見る表示はローカルタイムの方がいいですね。
むしろJST/UTC固定より、こういうときこそLocalTimeを使った方がいいのでは（JST固定だと動作端末のタイムゾーン情報が落ちてしまう）と思います。

ギリギリまでUTCで取り扱って出力時にLocalTimeに変換（日時文字列にタイムゾーンを含める）くらいでしょうか。

[keiji]

むしろ、ここにタイムゾーン関係の処理があったのか…LoggerServiceからしか使われないないから気づいてなかった。
JstNowについては、使われている箇所がLoggerServiceの1箇所しかない＋ログを出力するたびにタイムゾーンを取得する処理が走っているので、staticで持って一回で済むようにしたいですね。

Issueにある解決策と代替案でどちらかという意味では解決策の方「Timezone関係は1つのクラスにまとめる（#523 で統一する）」方向で行きたいですね。
一方、処理をすでにあるUtilsクラスにまとめるかは検討の余地があると考えています。TimezoneUtilsとか、もう少し用途がわかる名前にしたい。

（そういえば DateTimeUtility というクラスもあるんだった。けど、これはServiceとして取り扱う提案されているので、ここへの移行は良くないかも）。

[b-wind]

人間が見る表示はローカルタイムの方がいいですね。

人間が見る…… というよりは本来の目的からすると開発チームがトラブルシューティングのために見るのが存在の第一目的なのかなと。

端末自体のタイムゾーン情報は言語設定（CultureInfo）と一緒に必要な場所でログ出力する方が適切かなと。
端末自体の設定を変えることで「ログファイル内の日時表示方法」が変わるのは嬉しく無さそう。

ギリギリまでUTCで取り扱って出力時にLocalTimeに変換（日時文字列にタイムゾーンを含める）くらいでしょうか。
このあたりは出来れば Viewer側（COCOAの外）に任せたいのはあります。
専用のViewerでは無く Excel 等で開いている人も多いのかな？

[b-wind]

一方、処理をすでにあるUtilsクラスにまとめるかは検討の余地があると考えています。TimezoneUtilsとか、もう少し用途がわかる名前にしたい。

Utils クラス。使ってしまう気持ちは分かりますが、本件の様に見落としやすくなる一因だとは思います。

[b-wind]

私自身の運用経験から来る一般論ですが、クライアントとサーバーのログを突合等するケースを考えて同一のタイムゾーン・日時フォーマットの方が嬉しい等はありますね。

[b-wind]

話を広げてしまっていてなんなのですが、当 Issue の目的はあくまで処理方法の統一までとさせて戴きたいと考えます。
（検討の上 TimezoneUtils クラスなどに纏める・インスタンスの生成を効率化する所までは含む）

動作ログに出力する内容の変更は必要に応じて別 Issue にした方が良いかと思います。

[keiji]

AppConstantsに定数として定義して、アプリ内からは常に1つのインスタンスを使う（テストは別）ようにしました。