-
Notifications
You must be signed in to change notification settings - Fork 4
/
206.txt
1384 lines (1009 loc) · 58.2 KB
/
206.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
[14] [DFN[RFC 3339の日時形式]]は、 [[IETF]] が [DFN[RFC 3339]]
[DFN[[CITE[Date and Time on the Internet: Timestamps]]]]
で規定した[[日時形式]]です。
[192]
[[RFC 3339の日時形式]]は
[[ISO 8601の日時形式]]の[[プロファイル]]であり、
[[21世紀]]に入ってから作られた色々な [[IETF]] の[[プロトコル]]で採用されています。
[EG[
[101] [CODE[2006-04-13[[T]]14:12:53.4242+05:30]] は、
[[UTC]] から[TZ[5時間30分進んだ][+05:30]][[地方時]]における、
[TIME[平成18(2006)年4月13日14時12分53秒4242][2006-04-13T14:12:53.4242+05:30]]
を表しています。
]EG]
* 代替
[31] [[RFC 3339の日時形式]]は近年の [[IETF]] の仕様ではよく使われていますが、
それ以外ではあまり使われていません。 [[IETF]]
内でも細かなバリエーションがあって統一しきれていません。
[[IETF]] が規定する仕様を利用する場合を除き、本[[日時形式]]は使うべきではなさそうです。
[184] 類似した[[日時形式]]の中では [[HTMLの日時形式]]がより厳密に規定されており、
利用しやすくなっています。
* 仕様書
[REFS[
- [24] [CITE@en[RFC 3339 - Date and Time on the Internet: Timestamps]] ([TIME[2014-09-29 15:50:28 +09:00]] 版) <https://tools.ietf.org/html/rfc3339>
-- [79] [CITE@en[RFC 3339 - Date and Time on the Internet: Timestamps]] ([TIME[2017-05-07 16:17:18 +09:00]]) <https://tools.ietf.org/html/rfc3339#section-4>
-- [82] [CITE@en[RFC 3339 - Date and Time on the Internet: Timestamps]] ([TIME[2017-05-07 16:17:18 +09:00]]) <https://tools.ietf.org/html/rfc3339#section-5>
- [25] [CITE[RFC Errata Report]] ([TIME[2014-11-13 04:10:16 +09:00]] 版) <http://www.rfc-editor.org/errata_search.php?rfc=3339>
]REFS]
[196]
[[RFC 3339]] は [[IETF]] [[標準化過程RFC]] です。
状態は[[提案標準]]です ([[インターネット標準]]では''ありません'')。
[197]
なお、 [[RFC]] は、[[提案標準]]か[[インターネット標準]]かいずれかに関わらず、
採用すると定められた場面以外での強制力はありません。
[EG[
[198]
[[Atom 1.0]] は [[RFC 3339]] を使うと定めているので、
[[RFC 3339の日時形式]]を使わなければなりません。
]EG]
[EG[
[199]
新しい
[[Web API]]
で使う [[JSON]]
データ形式を設計するとき、
[[日時]]の表現に
[[RFC 3339の日時形式]]を使う義務はありません。
]EG]
[EG[
[240]
[[インターネットメール]]の [CODE[Date:]] [[ヘッダー]]では
[[RFC 5322の日時形式]]を使うと定められていて、
[[RFC 3339の日時形式]]は使えません。
]EG]
* 暦法
[186]
[[RFC 3339]] 内には [[ISO 8601]] の[[グレゴリオ暦]]記述法を使う、
というような簡単な言及のみしかありません。
不親切ですね ([[ISO 8601]] は有料です)。
[241]
[[RFC 3339の日時形式]]は [[ISO 8601のプロファイル]]ですので、
[[ISO 8601]] の規定が適用されます。
[SEE[ [[ISO 8601暦]] ]]
[242]
つまり [[RFC 3339]] の[[暦法]]も[[先発グレゴリオ暦]]です。
[EG[
[243]
[[明治改暦]]や[[グレゴリオ改暦]]より前の[[日時]]も記述できますが、
[[先発グレゴリオ暦]]で記述しなければなりません。
]EG]
[245]
[[旧暦]]、[[イスラム暦]]、[[ユリウス暦]]、
その他の[[暦法]]には対応していません。
[[グレゴリオ暦]]に変換して記述しなければなりません。
;; [246]
[[RFC 3339の日時形式]]はあくまで[[機械可読]]な[[情報交換]]用の構文に過ぎません。
[[人間]]用に表示するときは、
[[利用者]]に応じて適切に変換することが期待されます
(>>83)。
* 構文
[85] 構文は [[RFC 3339]] で [[ABNF]] により規定されています [SRC[>>82]]。
[86] [[ISO 8601]] の[[プロファイル]]である [SRC[>>82]] とされており、
[[ISO 8601]] と見比べれば自明ということなのか、規定された構文の[[意味]]はほとんど説明がありません。
不親切ですね ([[ISO 8601]] は有料です)。
[87] また、一般に [[RFC 3339の日時形式]]とされるものは[[生成規則]]
[CODE(ABNF)@en[date-time]] が[[受理]]する[[言語]]と解されていますが、
[[RFC 3339]] 自身にはどの[[生成規則]]が[[プロトコル]]等に埋め込まれて使われるべきものかが明記されていません。
よって、[[RFC 3339]] は[[日時]]形式を1つ規定しているという解釈もあれば、
[[日時]]、[[日付]]、[[時刻]]など複数の形式を規定しているという解釈もあります
(変種の項も参照)。
ただ、 [[RFC 3339]] に例示があるのはすべて [CODE(ABNF)@en[date-time]] です。
[247]
「[[RFC 3339]] の定める日時の形式」
と
「[[RFC 3339]] の[[生成規則]] [CODE[date-time]]」
が同じなのかどうかも、[[仕様書]]の厳密な解釈の問題としては存在します。
(>>104 も参照。)
;; [200]
[[近代]]的な[[標準技術仕様書][仕様書]]として見れば低品質と評さざるを得ませんが、
この時代の [[RFC]] ではまともな方でした。
;; [248]
こういう曖昧さを内包し、しかもそのことを見えにくくしてしまうのが、
[[ABNF]] のような[[形式言語]]による標準仕様の記述が好ましくないと
[[Web標準]]の世界で考えられるようになった一因ですね。
-*-*-
[89] [DFN[[CODE(ABNF)@en[date-time]]]] は、
[CODE(ABNF)@en[full-date]]、[CODE[T]]、[CODE(ABNF)@en[full-time]]
を連ねたものです。 [SRC[>>82]]
一般には1つの[[日時]]を表すと解されています。
[FIG(railroad)[
= [CODE(ABNF)@en[full-date]]
= |
== [CODE[T]]
= [CODE(ABNF)@en[full-time]]
]FIG]
[NOTE[
[201] ここで区切りに使う [CODE[T]] は、
[[ISO 8601]]
で定められたものです。
[[語源]]は [[time]]
と思われますが、
深い意味はなく、単なる区切りの記号と理解するべきものです。
[244] この [CODE[T]] があるために、
[[RFC 3339の日時形式]]は世界のどこの[[地域]]のどこの[[言語]]の[[日時表示]]としても不自然で、
専ら[[機械処理用][機械可読]]の[[日時形式]]としてしか利用できなくなっています。
なお、 >>17 も参照。
]NOTE]
-*-*-
[90] [DFN[[CODE[full-date]]]] は、
[[年月日]]を [CODE[-]] で連結したものです [SRC[>>82]]。
一般には1つの[[日付]]を表すと解されています。
[FIG(railroad)[
= [[年]]
= [CODE[-]]
= [[月]]
= [CODE[-]]
= [[日]]
]FIG]
-*-*-
[91] [DFN[[CODE[full-time]]]] は、[[時刻]]と[[時差]]を連ねたものです [SRC[>>82]]。
[FIG(railroad)[
= [[時刻]]
= [[時差]]
]FIG]
[95] [[時刻]]は、[[時]]、[[分]]、[[秒]]と[[秒の小数部]]を [CODE[:]] で連結したものです。
[SRC[>>82]]
[FIG(railroad)[
= [[時]]
= [CODE[:]]
= [[分]]
= [CODE[:]]
= [[秒]]と[[秒の小数部]]
]FIG]
-*-*-
[93] [[月]]は、 [CODE[01]] - [CODE[12]] の2桁の[[ASCII数字]]です [SRC[>>82]]。
[94] [[日]]は、 [CODE[01]] - ([CODE[28]], [CODE[29]], [CODE[30]], [CODE[31]] のいずれか)
の2桁の[[ASCII数字]]で、最大値は[[年]]と[[月]]による[[日の数]]です。 [SRC[>>82]]
[96] [[時]]は、 [CODE[00]] - [CODE[23]] の2桁の[[ASCII数字]]です [SRC[>>82]]。
;; [106] [[ISO 8601]] では認められている [CODE[24]] は、認められません [SRC[>>82]]。
[98] [[分]]は、 [CODE[00]] - [CODE[59]] の2桁の[[ASCII数字]]です [SRC[>>82]]。
[187] [[月]]、[[日]]、[[時]]、[[分]]はいずれも2桁の[[ASCII数字]]ですから、
1桁の場合[[先導0]]が必須となります。
[EG[
[188] [CODE[2019-3-5T4:3:3]] は不正です。
[CODE[2019-03-05T04:03:03]]
としなければなりません。
]EG]
* 年
[92] [[年]]は、4桁の[[ASCII数字]]です [SRC[>>82]]。
;; [[値域]]制限はありません。
[FIG(railroad)[
= [[ASCII数字]]
= [[ASCII数字]]
= [[ASCII数字]]
= [[ASCII数字]]
]FIG]
[19] [[ISO 8601]] (の当時の版) に従い、年号は4桁でなければなりません。1万年以降や0年よりも前は記述できません。
[1] この日付形式は[[2000年問題]]には対応していますが,
[[10000年問題]]には対応出来ません。
[SEE[ [[ISO 8601の日時形式]] ]]
;; [216]
将来的に5桁[[以上]]も認める形に拡張できるかもしれませんが、
[[固定長]]であるという特徴が失われるので注意する必要があります。
また、拡張したものは
[[RFC 3339の日時形式]]ではなくなります。
[2] なお、[TIME[西暦1年][year:1]]〜[TIME[999年][year:999]]を表す時には[[先導0]]
を補わなければならないことに注意が必要です。
[202]
[[暦]] (>>242) の違いにも注意が必要です。
[SEE[ [[ISO 8601の年]] ]]
-*-*-
[211]
[[ISO 8601]] の[[年]]は[[西暦年]]です。
[212]
[[元号年]]、[[民国紀元]]、[[ヒジュラ紀元]]など各国の[[紀年法]]には対応していません。
[[西暦年]]に変換して記述しなければなりません。
;; [215]
[[RFC 3339の日時形式]]はあくまで[[機械可読]]な[[情報交換]]用の構文に過ぎません。
[[人間]]用に表示するときは、
[[利用者]]に応じて適切に変換することが期待されます
(>>83)。
* 秒と秒の小数部
[97] [[秒]]は、 [CODE[00]] - ([CODE[58]], [CODE[59]], [CODE[60]] のいずれか)
の2桁の[[ASCII数字]]で、最大値は[[閏秒]]規則によります [SRC[>>82]]。
[99] [[秒の小数部]]は、 [CODE[.][小数点]] の後に1桁[[以上]]の
[[ASCII数字]]を連ねたものです [SRC[>>82]]。
[FIG(railroad)[
= [[ASCII数字]]
= [[ASCII数字]]
= ?
== [CODE[.][小数点]]
== +
=== [[ASCII数字]]
]FIG]
[18] [[RFC 3339]] は[[閏秒]]に対応しています。[[正閏秒]]として60秒を使うことができ、
[[負閏秒]]では59秒を使いません [SRC[>>82]]。
[105] [[応用]]は、
[[正閏秒]]が[[広告]]されるまで、
これを含む[[タイムスタンプ]]を[[生成]]するべきではありません。 [SRC[>>82]]
[32] 実装がこれを正しく扱えるのかどうかは定かではありません。
多くのシステムは[[閏秒のないUTC]]を採用しているので、
[[閏秒]]の[[タイムスタンプ]]を[[生成]]することはありませんし、
[[閏秒]]の[[タイムスタンプ]]を与えられたとき、
前後の[[秒]]と認識してしまうか、
不正な[[タイムスタンプ]]とみなされてしまう危険性があります。
あるいは[[閏秒]]かどうかの判断を回避するため、すべての[[分]]で60秒を認めてしまう実装もあるかもしれません。
[144] [[秒の小数部]]は任意の桁数が認められていますが、精度やプロトコル依存の制約の可否には何ら言及がありません。
* 時間帯
[4] [[UTC]] との[[時差を記述][時差の記述]]することができます。
;; [80] これは [[fingerprinting vector]] です。
[SEE[ [[日時のプライバシー]] ]]
[100] [[時差]]は、 [CODE[Z]] または数値時差です。
数値時差は、符号、[[時]]、[CODE[:]]、[[分]]を連ねたものです。
符号は、 [CODE[+]] または [CODE[-]] です。 [SRC[>>82]]
[FIG(railroad)[
= |
== [CODE[Z]]
== =
=== |
==== [CODE[+]]
==== [CODE[-]]
=== [[ASCII数字]]
=== [[ASCII数字]]
=== [CODE[:]]
=== [[ASCII数字]]
=== [[ASCII数字]]
]FIG]
[EG[
[220]
[[日本時間]] ([[中央標準時]]) は
[CODE[+09:00]]
となります。
]EG]
[78] [[時差]]は[[分]]単位です。[[秒]]単位の[[時差]]は記述できず、
適当な[[分]]単位の[[時差]]になおして記述するしかありません [SRC[>>79]]。
[185] [[RFC 822の日時形式]]とは違って、時と分の間に [CODE[:]]
が必須となっていることに注意。
これが欠けている誤った形式が使われることもあります。
[EG[
[221]
[CODE[+09:00]] が正しく、 [CODE[+0900]] は'''誤り'''です。
]EG]
-*-*-
[81] [[UTC]] での[[時刻]]はわかるものの[[地方時]]が不明なことを示す特別な[[時差]]表記
[CODE[-00:00]] があります。
;; [39] これは [[RFC 822の日時形式]]由来の慣習で、
[[ISO 8601の日時形式]]にはない独自の解釈です。
他の [[ISO 8601のプロファイル]]や [[HTMLの日時形式]]はこの解釈を採用していません。
[SEE[ [[-00:00]] ]]
;; [252] [[時差]]の不明な [[floating time]] とは異なるので注意。
* 指示子
[17] [CODE[T]] と [CODE[Z]] は、[[大文字]]でも[[小文字]]でも構いませんが、
[[大文字]]を使う[SHOULD[べき]]です [SRC[>>82]]。
[102] [[XML]] など[[大文字]]と[[小文字]]を区別する状況で使う[[プロトコル]]は、
[[大文字]]でなければならないと制約しても構いません。 [SRC[>>82]]
;; [103] [[インターネット]]の[[プロトコル]]でも、値の[[大文字]]と[[小文字]]を区別できない状況は稀です。
そもそも [[ISO 8601]] は[[大文字]]を使えない状況で[[小文字]]で代用しても良いとしているだけなので、
そのような状況がほとんど考えられない[[インターネット]]の新しい[[プロトコル]]向けの
[[RFC 3339]] がなぜわざわざ[[小文字]]も認めることにしたのかは、謎です。
(確かに [[IETF]] では[[大文字]]と[[小文字]]を区別しない[[プロトコル]]が伝統的ではあったのですが...)
[26] [[日時]]の境界は、 [[ABNF]] 構文では [CODE[T]] ([[大文字]]または[[小文字]])
とされています。しかし NOTE で、
[[応用]]は[[可読性]]のため[[間隔]]その他の他の区切りを選んでも構わない
[SRC[>>82]] とされています。
選択次第で
[[ISO 8601のプロファイル]]の範囲を逸脱してしまいます。
;; [104] [[ABNF]] では [CODE[T]] に限定されているということは、
「[[RFC 3339]] の [CODE(ABNF)@en[date-time]]」と明示的に参照している[[プロトコル]]においては、
[CODE[T]] を使うことが要求されていると解釈するべきでしょうか。
「[[RFC 3339]] の[[日時]]」のような曖昧な参照方法の[[プロトコル]]は、
他の区切り文字が認められている可能性があります。
* 処理
[145] 構文的に不正な値や値域を外れた値をどう解釈するべきかにはまったく言及されていません。
[249] 構文的に適正でも受信した装置が処理できない値 (過去すぎる、未来すぎるなど)
をどう処置するべきかにもまったく言及がありません。
[250] 適切かどうか判断し難い値や適切かどうかが変化した値 (具体的には[[閏秒]])
を受信した時どう処理するべきかは不明です。
[EG[
[251] 60秒と書かれた値は[[閏秒]]の実施不実施が決定されるまで適切な値かどうか不定ですし、
不実施が決定されてからは不適切な値になります。
]EG]
* レンダリング
[83] [[クライアント]]は、[[言語]]や[[時差]]に応じて適切に表示できるようにする[SHOULD[べきです]]
[SRC[>>82]]。
[SEE[ [[日時表示]] ]]
[181] つまり本[[日時形式]]はあくまで[[プロトコル]]の[[情報交換]]に用いられる構文を定めるものに過ぎず、
それを[[利用者エージェント]]がどのように[[利用者]]に提示するかは、
[[利用者エージェント]]の裁量の範囲内 ([[実装の品質]]の問題)
ということになります。
[EG[
[182] 例えば[[英語圏]]では[[月名]]を[[数字]]ではなく[[英語の名前][欧米月名]]で表示するのが適切かもしれません。
]EG]
[EG[
[253] 例えば[[日本]]では[[年]]を[[元号年]]と[[西暦年]]の併記で表示するべきかもしれません。
]EG]
[EG[
[183]
「○分前」のような [[ambtime]] 形式で表示するのが便利な場面もあるかもしれません。
]EG]
* 文脈
[84] 新しい[[インターネット]]の[[プロトコル]]では、
本形式を使う[SHOULD[べきです]] [SRC[>>82]]。
[FIG(middle list)[ [110] [[RFC 3339]] [CODE(ABNF)@en[date-time]] の採用例
- [225] [[CPIM]] [CODE[DateTime:]] [SRC[>>111]]
-- 変種: >>224
- [CODE(URI)@en[DAV:creationdate]] [SRC[>>109]]
- [CODE[yang:date-and-time]]
- [[媒体素片]] [CODE[clock][wall-clock time code]]
]FIG]
[FIG(middle list)[ [116] [[RFC 3339]] Section 5.6 [CSECTION@en[Internet Date/Time Format]] 形式の採用例
- [CODE(HTTP)@en[report-uri]] に送信される [[JSON]] の [CODE[date-time]] [SRC[>>115]]
]FIG]
[FIG(middle list)[ [124] [[RFC 3339]] の[[日時形式]]の採用例
- [[RDAP]] [SRC[>>123]]
]FIG]
[REFS[
- [111] [CITE@en[RFC 3862 - Common Presence and Instant Messaging (CPIM): Message Format]] ([TIME[2017-05-07 17:28:12 +09:00]]) <https://tools.ietf.org/html/rfc3862#section-4.4>
- [115] [CITE@en[RFC 7469 - Public Key Pinning Extension for HTTP]] ([TIME[2017-05-07 16:17:40 +09:00]]) <https://tools.ietf.org/html/rfc7469#section-3>
- [123] [CITE@en[RFC 7483 - JSON Responses for the Registration Data Access Protocol (RDAP)]] ([TIME[2017-05-07 17:28:01 +09:00]]) <https://tools.ietf.org/html/rfc7483#section-3>
]REFS]
[FIG(quote)[
[FIGCAPTION[
[34] [CITE@ja[ScalaでRSSフィードの処理を書いてみたら思ったより大変でした - argius note]]
([TIME[2016-01-07 17:36:27 +09:00]] 版)
<http://argius.hatenablog.jp/entry/20130830/1377867921>
]FIGCAPTION]
> RSS2.0の日付もRFC 3339になっているケースが割とありました。
]FIG]
;; [11] 本来は [[RFC 822の日時形式]]
* 変種
[204]
[[RFC 3339の日時形式]]には[[変種]]が無数にあります。
それらが「[[RFC 3339の日時形式]]」と (不正確に)
いわれることがあり、
円滑な[[情報交換]]の障害となっています。
;; [205]
これだけバリエーションが多いというのは、
[[RFC 3339]]
が要求に十分に応えられていない (が要求に近いものではある)
ことを表し、
[[標準化]]戦略が不完全だったことを意味しています。
ふつうなら標準仕様を改訂すれば済むことですが、
[[RFC]]
の改訂コストが極めて高い
[[IETF]]
の[[標準化手続き]]のためか、
長らく放置されています。
;; [254]
>>147 のように追加の制約が意味不明だったりすると、
何のために標準規格があって何のためにそれを採用したのか、
わからなくなってしまいますね。
[FIG(quote)[
[FIGCAPTION[
[146] [CITE@en[フォトコレクション | docomo Developer support | NTTドコモ]]
([TIME[2017-05-18 00:36:29 +09:00]])
<https://dev.smt.docomo.ne.jp/?p=docs.api.page&api_name=photo_collection&p_name=api_1>
]FIGCAPTION]
> タイムゾーンは任意に設定してよい。
> RFC 3339 の date-time フォーマットで 秒の1の位まで指定する。
> サンプル値) yyyy-mm-ddThh:mi:ss+09:00 (JSTの例)
> yyyy-mm-ddThh:mi:ssZ (UTCの例)
]FIG]
[147] 「秒の1の位まで指定する」の意図が不明。[[秒の小数部]]は使えないのだろうか。
** RFC 2518
[8] [[RFC 2518]] には、 [[RFC 3339]]
になるの前の [[I-D]] の規定の一部が[[コピペ]]されています。
[[ISO 8601]] 形式であること、 [[ABNF]] 構文、特別な[[時間帯]]である [CODE[-00:00]]
が含まれていますが、それ以外の説明は省かれています。 [SRC[>>107]]
[3] [[ABNF]] はほとんど [[RFC 3339]] と同じですが、[[負閏秒]]への言及が欠けています。
[108] [CODE(URI)@en[DAV:creationdate]] は、
[CODE(ABNF)@en[date-time]] を使うと規定されています [SRC[>>107]]。
[27] [[RFC 3339]] の出版を待たずに [[RFC 2518]] を出版するため、[[コピペ]]したのでしょう
[WEAK[(この時代の[[標準]]開発では [[IETF]] に限らずこのような中長期的な視点を欠いた仕事がしばしば見られました [SEE[ [[新規格の先行コピペ]] ]])]]。
[[RFC 2518]] の改訂版である [[RFC 4918]] では当該部分が削除され、 [[RFC 3339]]
の [CODE(ABNF)@en[date-time]] が参照されています [SRC[>>109]]。
[206]
このような方法を採られると、はたして [[RFC 2518]]
の規定するものが
[[RFC 3339の日時形式]]と同じものなのかどうか、
読者が個別に検証しなければならなくなります。
[207]
そして先述のような軽微な違いが存在します。
これを同じものと解釈してよいのかどうか、
見解は人によって異なり得ます。
こんなささいな違いから、
[[情報交換]]の失敗や大きな不具合につながることがあります。
[REFS[
- [107] [CITE@en[RFC 2518 - HTTP Extensions for Distributed Authoring -- WEBDAV]] ([TIME[2017-05-07 16:42:04 +09:00]]) <https://tools.ietf.org/html/rfc2518#section-23.2>
- [109] [CITE@en[RFC 4918 - HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)]] ([TIME[2017-05-07 17:54:50 +09:00]]) <https://tools.ietf.org/html/rfc4918#section-15.1>
]REFS]
** 秒の小数部を認めない変種
[122] [[SMTP]] では [CODE(ABNF)@en[date-time]] から[[秒の小数部]]を除いたものが使われる場合があります
[SRC[>>121]]。
[REFS[
- [121] [CITE@en[RFC 7293 - The Require-Recipient-Valid-Since Header Field and SMTP Service Extension]] ([TIME[2017-05-14 17:05:27 +09:00]]) <https://tools.ietf.org/html/rfc7293#section-3.1>
[FIG(quote)[
[FIGCAPTION[
[190] [CITE@ja[JavaScriptのプログラムに渡す時刻の文字列の形式は何が良いか – 或る阿呆の記]],
投稿日: 2018年9月11日 投稿者: hackle,
[最終更新] 2018年9月12日
([TIME[2019-07-08 13:01:39 +09:00]])
<https://hack-le.com/js-date-time-string/#ISO8601RFC3339>
]FIGCAPTION]
> この手の話を調べていると、ISO8601ではなくてRFC3339という呼ばれ方をしているものが散見される。「RFC3339 インターネット上の日付と時間:タイムスタンプ」
<http://www5d.biglobe.ne.jp/stssk/rfc/rfc3339j.html>
を読むと、RFC3339は、ISO8601拡張形式をシンプルかつ明示的に再定義したものだ。
> 文脈的にはほぼ同義のように扱われていることが多いが、RFC3339においてはミリ秒を定義せず、YYYY-mm-ddTHH:MM:SSZの形式であるようだ。自分はこの表記が一番馴染みがある。
]FIG]
[191] このような誤った情報はままみられます。
参照されている
「RFC3339 インターネット上の日付と時間:タイムスタンプ」
は [[RFC 3339]] の[[和訳][RFCの和訳]]で、
本当に「読」んだのであれば[[秒の小数部]]が使えることがかなり明確に書かれていることに気づいたはずです。
自分の「馴染み」に引っ張られてしまったのでしょうか。
]REFS]
** IETF の XML 系の変種
[15] [[IETF]] の [[XML]] 系仕様では [[XML Schema]] や [[RELAX NG]] のデータ型としては [CODE(XML)@en[[[xs:dateTime]]]]
([[XML Schemaの日付形式]]) を採用しつつ、本文で「[[RFC 3339]] の [CODE[[[date-time]]]] かつ [CODE[[[T]]]]
と [CODE[[[Z]]]] は[[大文字]]」とされていることが多いです。[[スキーマ]]が[[規定]]か[[参考]]かは仕様によりますが、
[[RFC 3339]] と [[XML Schema]] の両方の規定の[[積集合]]に従わなければならないということになります。
[SEE[ [[ISO 8601の日付形式]>>25]に、両者の比較があります。 ]]
[6] [CODE[xs:dateTime]] は[[10000年問題]]に対応していますが、
[[RFC 3339の日時形式]]は対応していません。
両方の規定に従うためには、9999年までの[[年]]しか扱えません。
-*-*-
[140] [[RFC 3863]] は、 [[PIDF]] [CODE(XMLe)@en[timestamp]] [[要素]]を
[[XML Schema]] では [CODE[xs:dateTime]] としながら、
本文では [[RFC 3339]] [DFN[IMPP datetime format]] で、
[CODE[T]] と [CODE[Z]] は[[大文字]]と規定しています [SRC[>>139, >>141]]。
[NOTE[
[142] [[RFC 3339の日時形式]]をそのまま使っている [[RFC 3862]] [[CPIM]] [SRC[>>111]]、
[[XML Schema]] で使っている [[RFC 3863]] [[PIDF]] [SRC[>>139]]、
そして [[RFC 3339]] はいずれも同じ [[ietf-impp]] [[WG]] で同時期に開発されたものでした。
つまり [[RFC 3339]] の様々なバリエーションの混乱は、はじめから存在していたのです。
[208] あとから新しい要件が発見されてバリエーションが生じたのでなく、
最初からバリエーションがあったとすると、
[[標準化]]戦略は最初から間違っていたと言わざるを得ません。
]NOTE]
[229]
[[RFC 3923]]
は
[[PIDF]]
の[[応用]]の1つを定めていましたが、
「UTC with no offset」
でなければ[MUST[ならない]]との追加の制約を[[規定]]していました。
[SRC[>>223]]
[REFS[
- [139] [CITE@en[[[RFC 3863]] - Presence Information Data Format (PIDF)]] ([TIME[2017-05-07 17:28:02 +09:00]]) <https://tools.ietf.org/html/rfc3863#section-4.1.7>
- [141] [CITE@en[[[RFC 3863]] - Presence Information Data Format (PIDF)]] ([TIME[2017-05-07 17:28:02 +09:00]]) <https://tools.ietf.org/html/rfc3863#section-4.4>
]REFS]
-*-*-
[133] [[RFC 5070]] では、 date-time string は DATETIME data type
で表されるとし、 date-time string は [[RFC 3339]] にある [[ISO 8601]]
の[[部分集合]]で表し、 DATETIME data type は [CODE[xs:dateTime]]
で実装される [SRC[>>132]] とされています。果たしてこれが何を意味するのかは不明です
([[RFC 3339の日時形式]]と [CODE[xs:dateTime]] の両方が適用されるという意味でしょうか)。
[135] その改訂版の [[RFC 7970]] では、謎の規定は削除されて、
[CODE[xs:dateTime]] だけになっています [SRC[>>134]]。
[138] [[RFC 5388]] は、 [[XML Schema 1.0]] 第2版 [CODE[xs:dateTime]]
としながらも、 [[RFC 3339]] の値に制約される [SRC[>>136、>>137]] と規定しています。
両方で共通して認められる値のみ指定可能ということなのでしょうが、
[CODE[-00:00]] がどう扱われるのかは、はっきりしません。
[REFS[
- [132] [CITE@en[RFC 5070 - The Incident Object Description Exchange Format]] ([TIME[2017-05-07 20:04:30 +09:00]]) <https://tools.ietf.org/html/rfc5070#section-2.8>
- [134] [CITE@en[RFC 7970 - The Incident Object Description Exchange Format Version 2]] ([TIME[2017-05-14 16:49:04 +09:00]]) <https://tools.ietf.org/html/rfc7970#section-2.7>
- [136] [CITE@en[RFC 5388 - Information Model and XML Data Model for Traceroute Measurements]] ([TIME[2017-05-07 16:57:43 +09:00]]) <https://tools.ietf.org/html/rfc5388#section-5.1>
- [137] [CITE@en[RFC 5388 - Information Model and XML Data Model for Traceroute Measurements]] ([TIME[2017-05-07 16:57:43 +09:00]]) <https://tools.ietf.org/html/rfc5388#section-7>
]REFS]
-*-*-
[70] [[WS-BaseFaults]] 1.2 は、[[時間帯]]が省略された場合には [[UTC]]
と解釈しなければ[MUST[なりません]]と規定しています。
[228] [[時間帯]]の省略は構文上認められていないのですが、
これは[[エラー処理]]の規定でしょうか?
*** Date construct (Atom 1.0)
[48] [[Atom]] [SRC[>>46]] および [[Metalink]] [SRC[>>47]]
では、[[日時]]の指定は [DFN[[[Date construct]]]] と呼ばれています。
[49] [[Date construct]] 中には[[空白]]を含めては[['''なりません''']]
[SRC@en[[[Atom 1.0]] 3.]]。
[50] [[RFC 3339]] の [CODE[[[date-time]]]] ([[RFC 3339の日付形式]]) でなければなりません。
記号 [CODE[[[T]]]] と [CODE[[[Z]]]] は[[大文字]]でなければ[['''なりません''']]。 [SRC[>>46, >>47]]
[51] [[RELAX NG]] [[スキーマ]] ([[参考]]) では [CODE[[[xsd:dateTime]]]] となっています [SRC[>>46, >>47]]。
[131] [[RFC 7049]] は、“[[RFC 4287]] 3.3 節で refine された [[RFC 3339]] 形式”
を採用しています [SRC[>>130]]。 これに [[RELAX NG]] [[スキーマ]] ([[参考]])
で示された制約まで含まれるのかは不明です。
[218]
「SmartFormat仕様書(Atom準拠)」
は
[[Atom 1.0]]
とは違う[[日時形式]]を規定しています (当然 [[Atom 1.0]] 仕様違反)。
[SEE[ [[SmartFormatの日時形式]] ]]
[REFS[
- [46] [CITE@en[RFC 4287 - The Atom Syndication Format]] ([TIME[2008-08-30 23:12:03 +09:00]] 版) <https://tools.ietf.org/html/rfc4287#section-3>
-- [CSECTION@en[3.3. Date Constructs]]
- [47] [CITE@en[RFC 5854 - The Metalink Download Description Format]] ([TIME[2014-09-14 16:54:14 +09:00]] 版) <https://tools.ietf.org/html/rfc5854#section-3.2>
- [130] [CITE@en[RFC 7049 - Concise Binary Object Representation (CBOR)]] ([TIME[2017-05-07 16:11:09 +09:00]]) <https://tools.ietf.org/html/rfc7049#section-2.4.1>
]REFS]
;; [53] [[Atom 0.3]] では [[W3C-DTF]] が用いられていました。 [[Atom 1.0]]
の定義とほとんど変わりませんが、厳密には多少の違いがあります。
[FIG(quote)[
[FIGCAPTION[
[41] [CITE@en[Commit e188b782a1dc1bd8e9e0006fea476b6c92fd04a7 to hakobe's pig - GitHub]] ([TIME[2009-05-24 10:33:12 +09:00]] 版) <http://github.com/hakobe/pig/commit/e188b782a1dc1bd8e9e0006fea476b6c92fd04a7>
]FIGCAPTION]
>Gmailのフィードがhoursが24以上の日付を返してくる
]FIG]
[42] [[W3C]] の[[メーリングリスト]]の[[アーカイブ]]の [[Atomフィード]]は、
[PRE(XML code)[
<updated>2014-03-01T11:01:35+0000(UT:C)</updated>
]PRE]
... のようなおかしな日付を出力します。
([[RFC 822の日付形式]]から変換するときに、[[注釈]]を考慮せずに[[時間帯]]の「:」を補っているようですね・・・。)
*** EPP
[54] [[EPP]] では、 [[RFC 3339]] と
[[XML Schema]] [CODE(XML)[[VAR[xsd:]][[dataTime]]]]
の両方の部分集合である日付形式を規定しています。
[REFS[
- [55] [[RFC 3730]] [CITE[Extensible Provisioning Protocol (EPP)]]
<urn:ietf:rfc:3730>
-- [CSECTION[5. Internationalization Considerations]]
- [56] [[RFC 3731]] [CITE[Extensible Provisioning Protocol (EPP) Domain Name Mapping]]
<urn:ietf:rfc:3731>
-- [CSECTION[2.4. Dates and Times]]
-- [CSECTION[5. Internationalization Considerations]]
- [57] [[RFC 3732]] [CITE[Extensible Provisioning Protocol (EPP) Host Mapping]]
<urn:ietf:rfc:3732>
-- [CSECTION[2.4. Dates and Times]]
-- [CSECTION[5. Internationalization Considerations]]
- [58] [[RFC 3733]] [CITE[Extensible Provisioning Protocol (EPP) Contact Mapping]]
<urn:ietf:rfc:3733>
-- [CSECTION[2.7. Dates and Times]]
-- [CSECTION[5. Internationalization Considerations]]
- [59] [[RFC 3915]] [CITE[Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)]]
<urn:ietf:rfc:3915>
-- [CSECTION[3.3. Dates and Times]]
]REFS]
[60] RFC 3730〜3733 によれば:
- [61] 基本的には [[RFC 3339の日付形式]] ([CODE(ABNF)[[[date-time]]]]) です。
- [62] [[時間帯]]は [CODE[Z]] でなければ'''なりません'''。
- [63] [CODE[T]] と [CODE[Z]] は大文字でなければ'''なりません'''。
[64] 例:
- [65] [SAMP[2000-06-06T22:00:00.0Z]]
- [66] [SAMP[2005-11-26T22:00:00.0Z]]
*** UTC 固定の変種
[SEE[ >>222 ]]
*** RFC 5070
[38] [[RFC 5070]] は、 [[RFC 3339]] と [CODE[xs:dateTime]] に加えて
[[ISO 8601:2000]] にも言及しています。これが[[適合性]]と処理にどう影響するのか評価するのは難しいです。
([[RFC 3339]] も [CODE[xs:dateTime]] も [[ISO 8601]] をベースにはしていますが、
細部は違っています。)
[FIG(quote)[
[FIGCAPTION[
[29] [CITE@en[RFC 5070 - The Incident Object Description Exchange Format]]
([TIME[2015-07-11 22:59:28 +09:00]] 版)
<https://tools.ietf.org/html/rfc5070#section-2.8>
]FIGCAPTION]
> Date-time strings are formatted according to a subset of ISO 8601:
2000 '''['''13''']''' documented in RFC 3339 '''['''12''']'''.
The DATETIME data type is implemented as an "xs:dateTime" '''['''3''']''' in the
schema.
]FIG]
** UTC 固定の変種
[224]
[[RFC 3923]]
は
[[CPIM]] メッセージ ([CODE[message/cpim]], >>225)
の[[応用]]の1つを規定するもので、
「UTC with no offset」
でなければ[MUST[ならない]]との追加の制約を定めていました。
[SRC[>>223]]
[226]
[CODE[Z]] か [CODE[z]] か [CODE[+00:00]] かには特に言及がありません。
[REFS[
- [223] [CITE@en[rfc3923]], [TIME[2021-06-22T03:13:59.000Z]] <https://datatracker.ietf.org/doc/html/rfc3923#section-6.9>
]REFS]
-*-*-
[117] [[RFC 7808]] は [[RFC 3339]] [CODE[date-time]]
の[[時間帯]]を [CODE[Z]] とするものを
[DFN[[RUBYB[UTC [CODE[date-time]]値]@en[UTC [CODE[date-time]] value]]]]と呼んでいるようです
[SRC[>>118]]。
[227]
「use a "Z" suffix, and not fixed numeric offsets」
と説明されており [SRC[>>118]]、曖昧ながら [CODE[Z]] でも [CODE[z]]
でも良さそうに読めます。
[REFS[
- [118] [CITE@en[RFC 7808 - Time Zone Data Distribution Service]] ([TIME[2017-05-14 17:06:59 +09:00]]) <https://tools.ietf.org/html/rfc7808>
]REFS]
-*-*-
[222] [[IETF]] の [[XML]] 系の変種 (>>15) で、更に [[UTC]]
限定の制約が付いたものがありました。
[67] [[RFC 3982]] は[[時間帯]]を [[UTC]] ([CODE[Z]])
に固定しています。 ([[XML Schema]] 定義では
[CODE(XML)[[VAR[xs:]]dateTime]] を使用。)
[REFS[
- [68] [[RFC 3982]] [CITE[IRIS: A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS)]]
<urn:ietf:rfc:3982>
-- [CSECTION[3.2.1. Privacy Labels]]
]REFS]
[69] [[EPPの日付形式]]は [CODE(XML)[[VAR[xs:]]dataTime]]
と [[RFC 3339の日付形式]]の両方の部分集合で、
時間帯を [CODE[Z]] に固定した上で [CODE[T]] と [CODE[Z]]
を[[大文字]]で記述すると規定しています。
([[XML Schema]] 定義では [CODE(XML)[[VAR[xs:]]dateTime]] を使用。)
** Sieve の日時
[125] [[Sieveの日時形式]]で [CODE[iso8601]] と呼ばれるものは、
[[RFC 3339]] の [CODE(ABNF)@en[date-time]] に次の制限を加えたものです [SRC[>>126]]。
- [127] [[大文字]]を使う
- [128] [TZ[+00:00]] ではなく [CODE[Z]] を使う
;; [129] [[UTC]] 以外の[[時差]]や [CODE[-00:00]] を使うことは禁止されていないようです。
[[一意性]]を意識した制約でしょうか。
[REFS[
- [126] [CITE@en[RFC 5260 - Sieve Email Filtering: Date and Index Extensions]] ([TIME[2017-05-07 22:48:17 +09:00]]) <https://tools.ietf.org/html/rfc5260#section-4.2>
]REFS]
** Syslog の日時
[20] [[Syslog]] の [CODE[[[TIMESTAMP]]]] は [[RFC 3339の日時形式]]を採用していますが、
次の制約を加えています [SRC[>>13]]。
[FIG(list)[
- [21] [[大文字]]を使わなければ[['''なりません''']]。
- [22] [CODE[[[T]]]] を使わなければ[['''なりません''']]。
- [44] [[閏秒]]を使っては[MUST[なりません]]。
]FIG]
[203]
[[負閏秒]]はどう扱われるのでしょうか。
[SEE[ [[閏秒のない時刻系]] ]]
[REFS[
- [13] [CITE@en[RFC 5424 - The Syslog Protocol]] ([TIME[2014-09-14 04:23:15 +09:00]] 版) <https://tools.ietf.org/html/rfc5424#section-6.2.3>
]REFS]
** JMAP の日時
[FIG(quote)[
[FIGCAPTION[
[35] [CITE[JSON Mail Access Protocol Specification (JMAP)]]
([TIME[2016-03-11 14:55:42 +09:00]] 版)
<http://jmap.io/spec.html>
]FIGCAPTION]
> Where the API specifies Date as a type, it means a string in RFC3339 date-time format, with the time-offset component always Z (i.e. the date-time MUST be in UTC time) and time-secfrac always omitted. The “T” and “Z” MUST always be upper-case. For example, "2014-10-30T14:12:00Z".
> Where the API specifies LocalDate as a type, it means a string in the same format as Date, but with the Z omitted from the end. This only occurs in relation to calendar events. The interpretation in absolute time depends upon the time zone for the event, which MAY not be a fixed offset (for example when daylight saving time occurs).
]FIG]
** [CODE[as2-date-time]]
[165] [[Activity Streams 2.0]] は [[RFC 3339]] の [CODE[date-time]]
から派生した [DFN[[CODE[as2-date-time]]]] を定義しています [SRC[>>164]]。
[166] [CODE[T]] と [CODE[Z]] は、[[大文字]]としなければ[MUST[なりません]]
[SRC[>>164]]。 (なぜか [[ABNF]] 構文では[[大文字]]でも[[小文字]]でも良いように書かれていますが、
[[英語]]では[[大文字]]のみ認めています [SRC[>>164]]。)
[167] [[秒]]とその直前の [CODE[:]] を、省略できます [SRC[>>164]]。
[[ABNF]] 構文では[[秒の小数部]]が存在するときも [CODE[:]] と[[秒の整数部]]を省略できるとされています
[SRC[>>164]]。これが意図通りなのかは、はっきりしません。
[169] [[データ型]]は [CODE[xsd:dateTime]] が使われています [SRC[>>168]]。
従って [[XML Schemaデータ型]]の制約も適用されるものと思われます。
ただ、 [[XML Schema]] の [CODE[xsd:dateTime]] では[[秒の整数部]]の省略は認められていませんが...
[REFS[
- [164] [CITE@en[Activity Streams 2.0]] ([TIME[2017-05-21 23:50:36 +09:00]]) <https://w3c.github.io/activitystreams/core/#h-dates>
- [168] [CITE@en[Activity Vocabulary]] ([TIME[2017-05-21 23:50:36 +09:00]]) <https://w3c.github.io/activitystreams/vocabulary/#h-termconventions>
]REFS]
** 日付のみの変種
[238]
[[RFC 3339]] は一般に[[日時形式]]を定義していると理解されていますが、
[[日付形式]]、[[時刻形式]]をも定義しているという解釈もあり得ます
(>>87)。
本項に示すのは[[日付形式]]を用いた事例です。
[5]
[[RFC 4646]] とその改訂版の [[RFC 5646]] は、 [[IANA登録簿]]の[[日付形式]]として [[RFC 3339]]
の [CODE(ABNF)@en[[[full-date]]]] を採用しています [SRC[>>37, >>120]]。
[FIG(quote)[
[FIGCAPTION[
[33] ([TIME[2015-10-04 21:50:44 +09:00]] 版)
<http://www.houjin-bangou.nta.go.jp/documents/k-resource-dl.pdf>
]FIGCAPTION]
>
,*凡例,*凡例の説明
,YYYY-MM-DD,インターネットの技術標準を議論するIETFによる、RFC3339に則った形式。平成27年10月5日(2015年10月5日)の場合は、「2015-10-05」と設定する。
]FIG]
[FIG(quote)[
[FIGCAPTION[
[239]
[CITE[k-resource-dl.pdf]], [TIME[2022-03-31T04:15:07.000Z]], [TIME[2022-06-16T08:48:40.198Z]] <https://www.invoice-kohyo.nta.go.jp/download/index.files/k-resource-dl.pdf#page=4>
]FIGCAPTION]
>
,*凡例,*凡例の説明
,YYYY-MM-DD,インターネットの技術標準を議論するIETFによる、RFC3339に則った形式。[BR[]]令和3年10月1日(2021年10月1日)の場合は、「2021-10-01」と設定する。
]FIG]
[119] [[RFC 7808]] は [[RFC 3339]] の [CODE(ABNF)@en[full-date]] を参照しています
[SRC[>>118]]。
[REFS[
- [37] [CITE@en[RFC 5646 - Tags for Identifying Languages]] ([TIME[2017-05-14 16:18:06 +09:00]]) <https://tools.ietf.org/html/rfc5646#section-3.1.1>
- [120] [CITE@en[RFC 5646 - Tags for Identifying Languages]] ([TIME[2017-05-14 16:18:06 +09:00]]) <https://tools.ietf.org/html/rfc5646#section-5.1>
]REFS]
** [CODE(URI)@en[tag:]] URL
[112] [CODE(URI)@en[tag:]] [[URL]] を規定する [[RFC 4151]] には、次のような規定があります。
[FIG(quote)[
[FIGCAPTION[
[113] [CITE@en[RFC 4151 - The 'tag' URI Scheme]] ([TIME[2017-05-07 16:48:27 +09:00]]) <https://tools.ietf.org/html/rfc4151>
]FIGCAPTION]
> The date is specified using one of the "YYYY",
"YYYY-MM" and "YYYY-MM-DD" formats allowed by the ISO 8601 standard
[4] (see also RFC 3339 [10]).
]FIG]
[114] この参照をどう解釈するべきなのかは謎過ぎます。なお [[ISO 8601]] は
[[Normative Reference]] で、 [[RFC 3339]] は [[Informative Reference]] です [SRC[>>113]]。
** I-JSON の変種
[FIG(quote)[
[FIGCAPTION[
[30] [CITE@en[RFC 7493 - The I-JSON Message Format]]
([TIME[2015-11-29 21:37:53 +09:00]] 版)
<https://tools.ietf.org/html/rfc7493#section-4.3>
]FIGCAPTION]
> It is RECOMMENDED that all such data
items be expressed as string values in ISO 8601 format, as specified
in '''['''RFC3339''']''', with the additional restrictions that uppercase rather
than lowercase letters be used, that the timezone be included not
defaulted, and that optional trailing seconds be included even when
their value is "00". It is also RECOMMENDED that all data items
containing time durations conform to the "duration" production in
Appendix A of RFC 3339, with the same additional restrictions.
]FIG]
;; [36] [[RFC 3339]] では[[秒]]はそもそも省略可能ではないのだが。
** TOML の変種
[171] [DFN[TOMLの日時形式]]は [[RFC 3339]] をベースにしたもので、4種類あります。
いずれも
[[TOML]]
で使われます。
[172]
[DFN[Offset Date-Time]] は、 [[時間]]の特定の[[瞬間]]を表すものです。
[[RFC 3339]] [CODE[date-time]] で、[[時差]]が指定されたものです。 [SRC[>>170]]