S時計

開発日記

2025年

１
ロケールはローカライズなので、書式。
タイムゾーンは、時差とサマータイム。
どっちも未設定なら環境設定を使われる。

２
暦の計算はGMTが基本。

３
dateクラスはGMTになる。カレンダー、ロケール、タイムゾーンの設定はない。
calendarクラスは、カレンダー、ロケール、タイムゾーンを設定できる。重要。
DateComponentsクラスは、カレンダー、ロケール、タイムゾーンを設定できる。意味はない。
dateFormatterクラスは、カレンダー、ロケール、タイムゾーンを設定できる。重要。

４
var calendar = Calendar(identifier: .gregorian)
calendar.locale = Locale(identifier: "ja_JP")
calendar.timeZone = TimeZone(identifier: "Asia/Tokyo")!
カレンダー、ロケール、タイムゾーンをしっかりと設定した方が良い。

５
var ff = DateComponents()
ff.calendar?.locale = Locale(identifier: "ja_JP")
ff.calendar?.timeZone = TimeZone(identifier: "Asia/Tokyo")!
設定できるが意味はない。
dateにするので基本はGMTになるからである。
もし、timeZoneを日本に設定するなら、計算する時の暦はJSTで統一する必要がある。
これは面倒なことだから、GMTで計算する方が良い。
//
ここはややこしい。
TimeZone(identifier: "Asia/Tokyo")!でGMTになる。
Timezone(secondsFromGMT: 0)!でJSTになる。
9時間を引かなくなるので、JSTの値を入れると、そのままで作られる。
そうするとその値はJSTになってしまう。
次にその値と計算する値はGMTなので狂ってしまう。
dateは(計算する値)はGMTであるので、それをJSTに変換し、そのままJSTの値でdateに変換してから計算となるので2度手間になる。

６
let formatter = DateFormatter()
formatter.calendar = Calendar(identifier: .gregorian)
formatter.locale = Locale(identifier: "ja_JP")
formatter.timeZone = TimeZone(identifier: "Asia/Tokyo")
カレンダー、ロケール、タイムゾーンをしっかりと設定した方が良い。

７
dateは秒の累積数と考えて良い。
calendarは秒を暦に変えてくれる。dateからcalendarに変換。
dateComponentsは暦をdateに変えてくれる。calendarからdateに変換。
dateFormatterはGMTをJSTに変えて、書式を付けてくれる。calendarから各国の書式に変換。

８
dateから要素を取り出す時に.componentを使う。
そのときはcalendarクラスで設定したカレンダー、ロケール、タイムゾーンを使うことになるので、自動でJSTに変換してくれる。
calendarクラスをダイレクトに使うことになるので、混乱する原因でもある。
dateからcalendar、calendarからdateFormatterとなるのを、 dateからダイレクト(dateからcalendar、calendarからdateFormatter)で表示できる。

９
dateからcalendarに変換。GMTからJST(GMTの概念も持つ)
calendarからdateに変換。dateComponentsを使う。JST(GMTの概念も持つ)からGMT。
calendarからdateFormatterに変換。JST(GMTの概念も持つ)を表示する。
dateから要素を取り出す。.componentを使う。GMTからJST。

１０
dateとcalendarを使うことで計算をGMTで行うことができる。
GMTを単純に累積秒として、そこから計算すると簡単に計算できる。
その計算したあとの秒をdateに変換できる。 dateからcalendarに変換することで暦にできる。
暦でも時間でも秒にすると計算しやすい。

１１
ある地点からの累積秒にするとどこでも同じになる。
それで足すなり引くなりしてもどの国と地域でも同じになる。
その累積秒を暦(カレンダー)に変換することで、各国のカレンダーになる。
//
累積秒のコード。
累積秒を日本の暦にするコード。
累積秒をアメリカニューヨークの暦にするコード。
どちらも同じです。また、正しい暦です。

１２
アメリカは、ニューヨークとカリフォルニアで時差があるから、アメリカ国内で商売している人は大変だと思う。
カリフォルニアに居てて、ニューヨークに商品を運ぶとなると、ニューヨーク時間の何時に持って来てになるのだろう。
カリフォルニア時間の何時に持って行くと間に合わなくなるね。

東京から北海道へ商品を何時に持って来ては時差がないので、簡単な話やん。時差があるとマジで大変だと思います。

日本は時差もなくサマータイムもないので、本当に幸せな国です。
マジで、時差とサマータイムは要らないです。

だから暦アプリは簡単で難しいのです。

１３
実行した日。
2025年10月12日(日)
13時12分11秒

実行した日の累積秒。
1760242331.942329

実行した日の累積秒をdateに戻し、 dateFormatterを東京で表示。
2025年10月12日(日)
13時12分11秒

実行した日の累積秒をdateに戻し、 dateFormatterをニューヨークで表示。
2025年10月12日(日)
0時12分11秒

//GMT
let d = Date()
//GMTを累計秒に変換する。
let timeInterval = d.timeIntervalSince1970
//GMTの累計秒をdateに変換する。
let date = Date(timeIntervalSince1970: timeInterval)

//dateFormatterを東京で表示。
dateFormatter.timeZone = TimeZone(identifier: "Asia/Tokyo")
//dateFormatterをニューヨークで表示。
dateFormatter.timeZone = TimeZone(identifier: "America/New_York")

1760242331.942329秒は、
日本時間で、
2025年10月12日(日)
13時12分11秒
を指します。
これを脳内だけで変換できるぐらいで、しかも各国な、それができて、やっと丁稚(でっち)や。

時計アプリは、ひょっこ、が作成してよいものではない。
素人が手を出してはダメなのです。

1760242331.942329秒は、
日本時間で、
2025年10月12日(日)
13時12分11秒
なので、1760242331.942329秒に86400秒を足すと、日本時間で、
2025年10月13日(日)
13時12分11秒
となる。

１４
1760242331.942329秒に秒を足していくと、どこかでオーバーフローするのではないかと思うが、 100年は余裕です。

32ビットで、2038年まで問題はないのです。
64ビットなら2100年以上、問題はないです。
もう、今の人は誰も生きていません。

そもそも32ビットのパソコンは、パソコンではない。
そんなパソコンを使っている者はいません。
そんなパソコンを使っている者が居てたとすれば、潔く買い替えしてください。

今後、地球がどうなるかは誰も分からない。
なので今、人類が後世に残せることを少しづつでもやらなくてはならないのです。
もし、荒廃した世界になった場合、 64ビットのパソコンがあるとどれだけ便利であるかを考えなくてはならないのです。
そこでチンケな32ビットのパソコンがあったら、みんな、がっかりやん。

スマホは64ビットなのにパソコンが32ビットはおかしいだろう。

2025/10/12