ISO 8601で、こういう日時の書き方はありですか？

どういう理由でその質問をしているのでしょうか？

想像するに、日時型を JSON 文字列にシリアライズし、その結果をデシリアライズする場合、どのような形式にすればよいのかという話のように思えます。もしそうであれば処理系が何かを書いていただけますか。

例えば、フォルダやファイル名や、ドキュメントに日時を書く際に、ISO 8601に倣って日時を書いた方が都合がいいかと思いまして。

ちなみに、Qiitaの質問のフォーマットが不手際で意見交換になってしまいました。正しくはQ&Aになります。

フォルダやファイル名や、ドキュメントに日時を書く際に

それなら ISO 8601 にこだわる必要はなくて、質問者さんが慣れ親しんだ形式にするのが良いと思うのですが？

上に私が書いた「日時型を JSON 文字列にシリアライズし、その結果をデシリアライズする」ような場合は、まずシリアライスの形式が処理系によって異なりますし、デシリアライズする場合も処理系によって受け付けないことがありますので、いろいろ考える必要がありますが。

もし、そのあたりに興味がありましたら以下の記事を見てください。

日付時刻と JSON 文字列
http://surferonwww.info/BlogEngine/post/2017/08/27/conversion-of-date-or-datetime-to-json-string.aspx

JSON 文字列の日付時刻のデシリアライズ
http://surferonwww.info/BlogEngine/post/2022/02/18/how-json-string-denoted-as-datetime-deserialized.aspx

申し訳ございませんが、私はweb系には疎くて「シリアライズ」の用語にピンと来ないのですが。

このQ&Aの趣旨としては、自分が質問内容に挙げた例(記法)がISO 8601に沿っているのか？という事実が気になったので質問をしたのですが。

ISO 8601自体について詳しい方がいましたら、ご回答いただけますと助かります。

@SurferOnWwwさん

それなら ISO 8601 にこだわる必要はなくて、質問者さんが慣れ親しんだ形式にするのが良いと思うのですが？

自分が慣れ親しんだ形式の一つがISO 8601で、

既にある規格や表記法になるべく倣った方が、例えば文字列検索(正規表現とか)やファイル検索の時に都合がいいと思うのですが。

規格書にアクセスできないため Wikipedia からの引用ですが、

ss, mm:ss の部分は省略可能で hh:mm, hh の形式も使用可能である。

よって

• 2023-07-20T10:05 (あるいは、基本形式で20230720T1005)
• 2023-07-20T10 (あるいは、基本形式で20230720T10)

はありです。

• 2023-07-20T+09:00 または、2023-07-20+09:00

hh は省略できないので 2023-07-20T+09:00 は不正でしょうが、時刻そのものを省略して日付＋時差と考えれば 2023-07-20+09:00 はありかもしれません。

余談ですが YYYYMM が禁止されているのは古い版の規格で許されていた YYMMDD と重複するせいだと思われます。

どこまで(あるいはどういう風に)記法を自在に組み替えていいか？　の判断はどこを参照・参考にすればよいでしょうか？

究極的には ISO 8601 の規格書を参照すべきですが2万円くらいします。正確性が最重要なのでなければよくまとまっている Suikawiki の記事を参照するといいと思います。 https://wiki.suikawiki.org/n/ISO%208601

私はweb系には疎くて「シリアライズ」の用語にピンと来ないのですが。

「web系」でなくても、例えば構成ファイルが JSON 形式で、それから日時データを読んできて、処理系で使う日時型にデシリアライズ（パース）するというようなことは良くある話ですよ。

まぁ、それは置いといて・・・

このQ&Aの趣旨としては、自分が質問内容に挙げた例(記法)がISO 8601に沿っているのか？という事実が気になったので質問をしたのですが。

質問者さんが最初の投稿で書いた以下が ISO 8601 でアリか否かということが質問ですか。それらに限った話で良いのですか。

2023-07-20T10:05
20230720T1005
2023-07-20T10
20230720T10
2023-07-20T+09:00
2023-07-20+09:00
20230720T+0900
20230720+0900

ただし、

例えば文字列検索(正規表現とか)やファイル検索の時に都合がいいと思うのですが。

と言う話に重きを置くなら、それは質問者さんが使っている処理系が受け入れる形式と言う話になるはずで、上の私が書いた「デシリアライズする場合も処理系によって受け付けないことがありますので、いろいろ考える必要があります」と言うことにもなります。（デシリアライズ＝文字列を処理系の日時型にパースすると思ってください）

> @albireoさん

問題として、「ISO 8601による日時表記が意外と長い¹」と個人的に感じて。部分的に省く事はできないものか？と素朴な疑問として思ったのですが。

・タイムゾーンの部分だけを除いたり（[日付][時刻]までの表現に対して必ず[時差]を付加しないといけないのか？）

ちょっと別の話として、

・日付記入時は「日本時差環境に居る」というような意図を示すのに、「日時」の「時」を除いて、日付とタイムゾーンだけは可能か？

というのが例の意図なのですが。言葉足らずで申し訳ございません。

> @uasiさん

基本形式で20230720T10

日付＋時差と考えれば 2023-07-20+09:00 はありかもしれません。

参考になります。

余談ですが YYYYMM が禁止されているのは古い版の規格で許されていた YYMMDD と重複するせいだと思われます。

大元のISO 8601の規格書も提示していただいたり補足な質問に答えていただきありがとうございます。

自分はWikipediaの記事ぐらいしか読んでなかったので参考になりました。

> @SurferOnWwwさん

質問者さんが最初の投稿で書いた以下が ISO 8601 でアリか否かということが質問ですか。それらに限った話で良いのですか。

そうです。

プログラマーやエンジニア的には、広くあるいはもっと考慮するべき事が他にあるのだろうとは思いますが。

自分はうまく説明できない事もあって、こう言わせてください、

「(この質問者は)想像しえない・解せない考え方や規格の使い方をしてる…」　と思っていただいて構いません…。

〔中略〕
2023-07-20T+09:00
20230720T+0900

は不可という事を、他の回答者の方がお答えいただいて一応納得しましが、それらについて異議やほかに何かあればご自由に仰ってください。

もう1つ追加で些細な質問の例になりますが、

2023-07-20T10: や 2023-07-20+09:という表記は規定的に不可ですよね？

2023-07-20T10: や 2023-07-20+09:という表記は規定的に不可ですよね？

規格書の4.2.2を要約した Suikawiki の記述を根拠にすると、時刻の末尾にコロンが来る表現は定義されていないので不可です。

> @uasiさん

定義外は不可なのですね。 自分は規格について無知でした。重ねてありがとうございます。

2023-07-20T10の表現は可能と知り、ふと、思ったのですが、

2023-07-20T10のように、[時差]表現を省いた場合、どういった解釈がされるようになるのでしょうか？ 　例えば、暗黙でタイムゾーンは「Z」とかになったりしますか？

[時差]表現を省いた場合、どういった解釈がされるようになるのでしょうか？

タイムゾーン指定子を省略した日時表現は時差についての情報を持ちません。暗黙的に決まるということはなく、その日時表現を解釈する人あるいはプログラムが（UTC の可能性も含む）どのタイムゾーンかを決めるものだと思います。

質問者さんが最初の投稿で書いた以下が ISO 8601 でアリか否かということが質問ですか。それらに限った話で良いのですか。

2023-07-20T10:05
20230720T1005
2023-07-20T10
20230720T10
2023-07-20T+09:00
2023-07-20+09:00
20230720T+0900
20230720+0900

そうです。

Wikipedia の英語版を読んではいかがですか？ Wikipedia なので間違いないという保証はないですが、少なくとも日本語版よりは良さそうです。

ISO 8601
https://en.wikipedia.org/wiki/ISO_8601

問題は以下の例の時間と時差の記述の部分で（それら以外の 4 例は OK。下の例も日付部分は OK）、

2023-07-20T+09:00
2023-07-20+09:00
20230720T+0900
20230720+0900

まず、T を省くのは、

"As of ISO 8601-1:2019, the basic format is T[hh][mm][ss] and the extended format is T[hh]:[mm]:[ss]. Earlier versions omitted the T (representing time) in both formats."

"In ISO 8601:2004 it was permitted to omit the "T" character by mutual agreement as in "200704051430",[36] but this provision was removed in ISO 8601-1:2019."

と言うことだそうで、ISO 8601-1:2019 準拠で Earlier versions はダメなら T を省くのはダメということになります。

時間を省いて時差だけでよいかですが、Wikipedia には以下のように書いてありました。

"If a time zone designator is required, it follows the combined date and time. For example, "2007-04-05T14:30Z" or "2007-04-05T12:30−02:00"."

なのでダメっぽいです。

それ以上は自分にとっては時間と労力をかけてまで調べる意味がないので調べてません。

質問者さんの方で調べていただくか、他の回答者の答えをお待ちください

手打ちしてられない

これはもう、「長い文字列を手打ちするという代償を払ってでもISO 8601形式にする必要があるのか？」まで考えた方がいいような…
とはいってもISO8601は「人間に理解可能な範囲で可能な限り短い文字列に収めるための仕様」と言えるので、区切り文字ほぼなしの基本形式より短くしようとすればどこかに無理が生じます。
たとえばユリウス日にするとか、16進数表記(年が3桁、月時が1桁になる)にするとか。

というわけで文字列の長さを気にするなら「ISO8601ならどう書けるか」より先に「時刻や時差は本当に必要なのか」(手打ち量を増やすのに見合った価値があるのか)じゃないでしょうか。

> @uasiさん

その日時表現を解釈する人が、例えば「書き手が日本人っぽいな」と思ったら、タイムゾーンが日本として一応考慮されるのですね。

その日時表現を解釈する人あるいはプログラムが`UTC の可能性も含む）どのタイムゾーンかを決めるものだと思います。

そのような事¹が知れてよかったです。言葉足らずな私の意図も汲んでくださり助かりました。

> @SurferOnWwwさん

"In ISO 8601:2004 it was permitted to omit the "T" character by mutual agreement as in "200704051430",[36] but this provision was removed in ISO 8601-1:2019."

もし自在に勝手に記法を一部変えたISO 8601な日時表現をしても、その時はそれが規定内でも、長い目で見ると規定外な日時表現な書き方になってしまう可能性が浮かびました。

ちゃんとやるなら古い版も含め規格書を読んだり考慮する必要がありそうですね…。

(多分それはISO 8601の件だけに言える事じゃないとは思いますが。)

なのでダメっぽいです。

あーそうでしたか！

それ以上は自分にとっては時間と労力をかけてまで調べる意味がないので調べてません。

おそらく、どちらかというと些末な問題であろうこの質問に対して、調べてくださり感謝いたします。

> @albireoさん

とはいってもISO8601は〔中略〕

そうなんですね。自分の(ISO 8601への)考え方な認識が一応確認できてよかったです。

というわけで文字列の長さを気にするなら「ISO8601ならどう書けるか」より先に「時刻や時差は本当に必要なのか」(手打ち量を増やすのに見合った価値があるのか)じゃないでしょうか。

自分の余談になると思いますが、自分が意見交換の途中にも書いた通り¹、いわゆるデファクトスタンダードに倣わない感じと言いますか、

もし例えば、自分で何か新しく日時表現記法を作る・自分の中で日時表記を定める　とかすると、それはそれで多分面倒だなとは思うので地味に悩み所なのですがね。余談ですね。

その日時表現を解釈する人が、例えば「書き手が日本人っぽいな」と思ったら、タイムゾーンが日本として一応考慮されるのですね。

他の可能性としてたとえば、「この API が返すタイムゾーンなしの ISO 8601日時表現はマシンのシステムタイムゾーンと同じとする」と定義された API があれば、 呼び出し側はそのように解釈することが（API 規約上は）求められますし、「この文書の日時表現は日本時間である」と書かれた文書を読む人はそう読むことが（書き手との合意を満たすためには）求められるわけです。 ISO 8601 の立場としては、そのような取り決めは表現を交換する二者間でよろしくやるもので、仕様の中では関知しないということだと思います。

ISO 8601 相当も含んでいるというインターネットプロトコルの規格 RFC 3339 は無料で公開されています。

この中で人間による可読性についても言及されており、表示方法はクライアントが地域文化に適した形に変換するのが望ましい (規格に基づく形式自体は人にとって必ずしも十分に読み書きしやすくはない) ということが書かれています。 あくまでもデータ交換用のフォーマットなのです。

人間向けに多少の配慮をすることでデバッグコストは下がるという理由で手頃なところでバランスをとった結果の仕様なので人が手作業で入出力するという前提のときにはこの仕様はマッチしないでしょう。

規格は法律のような強制力があるわけではなくコミュニケーション手段です。 なんらかの約束のときに長々とした仕様を記載するよりは ISO 8601 だと一言で済ますほうが楽という程度のことでしかありません。

すでに約束した状況ならば厳密に従うべきですが、これから決めることについて用途にマッチしない規格を選ぶ強い理由はないでしょう。

不都合が生じたときに機械的に変換が可能なように配慮しておけば最初から ISO 8601 に厳密にする必要もなさそうに感じます。

> @uasiさん @SaitoAtsushiさん

私事情により返信が遅れましたが、
返信補足や そもそもなコンセプト含め説明して頂きありがとうございました。