例えば、 2023-07-20T10:05 (あるいは、基本形式で20230720T1005) とか、 2023-07-20T10 (あるいは、基本形式で20230720T10) と...

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

@410 2023年07月20日に投稿

> @albireoさん

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

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

ちょっと別の話として、

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

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

「2023-07-20 15時」でも実際に書いてても長いのに「2023-07-20T15:56+09:00」なんて、いざ手打ちしてられない。 ↩

@410 2023年07月20日に投稿

> @uasiさん

基本形式で20230720T10

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

参考になります。

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

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

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

@410 2023年07月20日に投稿

> @SurferOnWwwさん

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

そうです。

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

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

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

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

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

@410 2023年07月20日に投稿

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

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

@uasi 2023年07月20日に投稿

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

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

@410 2023年07月20日に投稿

> @uasiさん

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

@410 2023年07月20日に投稿

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

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

@uasi 2023年07月20日に投稿

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

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

@SurferOnWww 2023年07月20日に投稿

質問者さんが最初の投稿で書いた以下が 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"."

なのでダメっぽいです。

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

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

@albireo 2023年07月21日に投稿

手打ちしてられない

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

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

@410 2023年07月21日に投稿

> @uasiさん

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

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

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

(日時の読み手側の認識についても) ↩

@410 2023年07月21日に投稿

> @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の件だけに言える事じゃないとは思いますが。)

なのでダメっぽいです。

あーそうでしたか！

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

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

@410 2023年07月21日に投稿

> @albireoさん

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

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

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

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

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

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

@uasi 2023年07月21日に投稿

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

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

@SaitoAtsushi 2023年07月21日に投稿

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

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

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

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

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

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

@410 2023年07月29日に投稿

> @uasiさん @SaitoAtsushiさん

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

あなたも回答してみませんか :)

新規登録

すでにアカウントを持っている方はログイン

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

2023-09-01 追記:

> @albireoさん

> @uasiさん

> @SurferOnWwwさん

> @uasiさん

> @uasiさん

> @SurferOnWwwさん

> @albireoさん

> @uasiさん @SaitoAtsushiさん

あなたも回答してみませんか :)

人気の質問