1
2
3
4
5
6
7Network Working Group G. Klyne
8Request for Comments: 3339 Clearswift Corporation
9Category: Standards Track C. Newman
10 Sun Microsystems
11 July 2002
12
13
14 Date and Time on the Internet: Timestamps
15
16Status of this Memo
17
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
23
24Copyright Notice
25
26 Copyright (C) The Internet Society (2002). All Rights Reserved.
27
28Abstract
29
30 This document defines a date and time format for use in Internet
31 protocols that is a profile of the ISO 8601 standard for
32 representation of dates and times using the Gregorian calendar.
33
34Table of Contents
35
36 1. Introduction ............................................ 2
37 2. Definitions ............................................. 3
38 3. Two Digit Years ......................................... 4
39 4. Local Time .............................................. 4
40 4.1. Coordinated Universal Time (UTC) ...................... 4
41 4.2. Local Offsets ......................................... 5
42 4.3. Unknown Local Offset Convention ....................... 5
43 4.4. Unqualified Local Time ................................ 5
44 5. Date and Time format .................................... 6
45 5.1. Ordering .............................................. 6
46 5.2. Human Readability ..................................... 6
47 5.3. Rarely Used Options ................................... 7
48 5.4. Redundant Information ................................. 7
49 5.5. Simplicity ............................................ 7
50 5.6. Internet Date/Time Format ............................. 8
51 5.7. Restrictions .......................................... 9
52 5.8. Examples ............................................. 10
53 6. References ............................................. 10
54 7. Security Considerations ................................ 11
55
56
57
58Klyne, et. al. Standards Track [Page 1]
59
60RFC 3339 Date and Time on the Internet: Timestamps July 2002
61
62
63 Appendix A. ISO 8601 Collected ABNF ....................... 12
64 Appendix B. Day of the Week ............................... 14
65 Appendix C. Leap Years .................................... 14
66 Appendix D. Leap Seconds ..............................,... 15
67 Acknowledgements .......................................... 17
68 Authors' Addresses ........................................ 17
69 Full Copyright Statement .................................. 18
70
711. Introduction
72
73 Date and time formats cause a lot of confusion and interoperability
74 problems on the Internet. This document addresses many of the
75 problems encountered and makes recommendations to improve consistency
76 and interoperability when representing and using date and time in
77 Internet protocols.
78
79 This document includes an Internet profile of the ISO 8601 [ISO8601]
80 standard for representation of dates and times using the Gregorian
81 calendar.
82
83 There are many ways in which date and time values might appear in
84 Internet protocols: this document focuses on just one common usage,
85 viz. timestamps for Internet protocol events. This limited
86 consideration has the following consequences:
87
88 o All dates and times are assumed to be in the "current era",
89 somewhere between 0000AD and 9999AD.
90
91 o All times expressed have a stated relationship (offset) to
92 Coordinated Universal Time (UTC). (This is distinct from some
93 usage in scheduling applications where a local time and location
94 may be known, but the actual relationship to UTC may be dependent
95 on the unknown or unknowable actions of politicians or
96 administrators. The UTC time corresponding to 17:00 on 23rd March
97 2005 in New York may depend on administrative decisions about
98 daylight savings time. This specification steers well clear of
99 such considerations.)
100
101 o Timestamps can express times that occurred before the introduction
102 of UTC. Such timestamps are expressed relative to universal time,
103 using the best available practice at the stated time.
104
105 o Date and time expressions indicate an instant in time.
106 Description of time periods, or intervals, is not covered here.
107
108
109
110
111
112
113
114Klyne, et. al. Standards Track [Page 2]
115
116RFC 3339 Date and Time on the Internet: Timestamps July 2002
117
118
1192. Definitions
120
121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
123 document are to be interpreted as described in RFC 2119 [RFC2119].
124
125 UTC Coordinated Universal Time as maintained by the Bureau
126 International des Poids et Mesures (BIPM).
127
128 second A basic unit of measurement of time in the
129 International System of Units. It is defined as the
130 duration of 9,192,631,770 cycles of microwave light
131 absorbed or emitted by the hyperfine transition of
132 cesium-133 atoms in their ground state undisturbed by
133 external fields.
134
135 minute A period of time of 60 seconds. However, see also the
136 restrictions in section 5.7 and Appendix D for how
137 leap seconds are denoted within minutes.
138
139 hour A period of time of 60 minutes.
140
141 day A period of time of 24 hours.
142
143 leap year In the Gregorian calendar, a year which has 366 days.
144 A leap year is a year whose number is divisible by
145 four an integral number of times, except that if it is
146 a centennial year (i.e. divisible by one hundred) it
147 shall also be divisible by four hundred an integral
148 number of times.
149
150 ABNF Augmented Backus-Naur Form, a format used to represent
151 permissible strings in a protocol or language, as
152 defined in [ABNF].
153
154 Email Date/Time Format
155 The date/time format used by Internet Mail as defined
156 by RFC 2822 [IMAIL-UPDATE].
157
158 Internet Date/Time Format
159 The date format defined in section 5 of this document.
160
161 Timestamp This term is used in this document to refer to an
162 unambiguous representation of some instant in time.
163
164 Z A suffix which, when applied to a time, denotes a UTC
165 offset of 00:00; often spoken "Zulu" from the ICAO
166 phonetic alphabet representation of the letter "Z".
167
168
169
170Klyne, et. al. Standards Track [Page 3]
171
172RFC 3339 Date and Time on the Internet: Timestamps July 2002
173
174
175 For more information about time scales, see Appendix E of [NTP],
176 Section 3 of [ISO8601], and the appropriate ITU documents [ITU-R-
177 TF].
178
1793. Two Digit Years
180
181 The following requirements are to address the problems of ambiguity
182 of 2-digit years:
183
184 o Internet Protocols MUST generate four digit years in dates.
185
186 o The use of 2-digit years is deprecated. If a 2-digit year is
187 received, it should be accepted ONLY if an incorrect
188 interpretation will not cause a protocol or processing failure
189 (e.g. if used only for logging or tracing purposes).
190
191 o It is possible that a program using two digit years will
192 represent years after 1999 as three digits. This occurs if the
193 program simply subtracts 1900 from the year and doesn't check
194 the number of digits. Programs wishing to robustly deal with
195 dates generated by such broken software may add 1900 to three
196 digit years.
197
198 o It is possible that a program using two digit years will
199 represent years after 1999 as ":0", ":1", ... ":9", ";0", ...
200 This occurs if the program simply subtracts 1900 from the year
201 and adds the decade to the US-ASCII character zero. Programs
202 wishing to robustly deal with dates generated by such broken
203 software should detect non-numeric decades and interpret
204 appropriately.
205
206 The problems with two digit years amply demonstrate why all dates and
207 times used in Internet protocols MUST be fully qualified.
208
2094. Local Time
210
2114.1. Coordinated Universal Time (UTC)
212
213 Because the daylight saving rules for local time zones are so
214 convoluted and can change based on local law at unpredictable times,
215 true interoperability is best achieved by using Coordinated Universal
216 Time (UTC). This specification does not cater to local time zone
217 rules.
218
219
220
221
222
223
224
225
226Klyne, et. al. Standards Track [Page 4]
227
228RFC 3339 Date and Time on the Internet: Timestamps July 2002
229
230
2314.2. Local Offsets
232
233 The offset between local time and UTC is often useful information.
234 For example, in electronic mail (RFC2822, [IMAIL-UPDATE]) the local
235 offset provides a useful heuristic to determine the probability of a
236 prompt response. Attempts to label local offsets with alphabetic
237 strings have resulted in poor interoperability in the past [IMAIL],
238 [HOST-REQ]. As a result, RFC2822 [IMAIL-UPDATE] has made numeric
239 offsets mandatory.
240
241 Numeric offsets are calculated as "local time minus UTC". So the
242 equivalent time in UTC can be determined by subtracting the offset
243 from the local time. For example, 18:50:00-04:00 is the same time as
244 22:50:00Z. (This example shows negative offsets handled by adding
245 the absolute value of the offset.)
246
247 NOTE: Following ISO 8601, numeric offsets represent only time
248 zones that differ from UTC by an integral number of minutes.
249 However, many historical time zones differ from UTC by a non-
250 integral number of minutes. To represent such historical time
251 stamps exactly, applications must convert them to a representable
252 time zone.
253
2544.3. Unknown Local Offset Convention
255
256 If the time in UTC is known, but the offset to local time is unknown,
257 this can be represented with an offset of "-00:00". This differs
258 semantically from an offset of "Z" or "+00:00", which imply that UTC
259 is the preferred reference point for the specified time. RFC2822
260 [IMAIL-UPDATE] describes a similar convention for email.
261
2624.4. Unqualified Local Time
263
264 A number of devices currently connected to the Internet run their
265 internal clocks in local time and are unaware of UTC. While the
266 Internet does have a tradition of accepting reality when creating
267 specifications, this should not be done at the expense of
268 interoperability. Since interpretation of an unqualified local time
269 zone will fail in approximately 23/24 of the globe, the
270 interoperability problems of unqualified local time are deemed
271 unacceptable for the Internet. Systems that are configured with a
272 local time, are unaware of the corresponding UTC offset, and depend
273 on time synchronization with other Internet systems, MUST use a
274 mechanism that ensures correct synchronization with UTC. Some
275 suitable mechanisms are:
276
277 o Use Network Time Protocol [NTP] to obtain the time in UTC.
278
279
280
281
282Klyne, et. al. Standards Track [Page 5]
283
284RFC 3339 Date and Time on the Internet: Timestamps July 2002
285
286
287 o Use another host in the same local time zone as a gateway to the
288 Internet. This host MUST correct unqualified local times that are
289 transmitted to other hosts.
290
291 o Prompt the user for the local time zone and daylight saving rule
292 settings.
293
2945. Date and Time format
295
296 This section discusses desirable qualities of date and time formats
297 and defines a profile of ISO 8601 for use in Internet protocols.
298
2995.1. Ordering
300
301 If date and time components are ordered from least precise to most
302 precise, then a useful property is achieved. Assuming that the time
303 zones of the dates and times are the same (e.g., all in UTC),
304 expressed using the same string (e.g., all "Z" or all "+00:00"), and
305 all times have the same number of fractional second digits, then the
306 date and time strings may be sorted as strings (e.g., using the
307 strcmp() function in C) and a time-ordered sequence will result. The
308 presence of optional punctuation would violate this characteristic.
309
3105.2. Human Readability
311
312 Human readability has proved to be a valuable feature of Internet
313 protocols. Human readable protocols greatly reduce the costs of
314 debugging since telnet often suffices as a test client and network
315 analyzers need not be modified with knowledge of the protocol. On
316 the other hand, human readability sometimes results in
317 interoperability problems. For example, the date format "10/11/1996"
318 is completely unsuitable for global interchange because it is
319 interpreted differently in different countries. In addition, the
320 date format in [IMAIL] has resulted in interoperability problems when
321 people assumed any text string was permitted and translated the three
322 letter abbreviations to other languages or substituted date formats
323 which were easier to generate (e.g. the format used by the C function
324 ctime). For this reason, a balance must be struck between human
325 readability and interoperability.
326
327 Because no date and time format is readable according to the
328 conventions of all countries, Internet clients SHOULD be prepared to
329 transform dates into a display format suitable for the locality.
330 This may include translating UTC to local time.
331
332
333
334
335
336
337
338Klyne, et. al. Standards Track [Page 6]
339
340RFC 3339 Date and Time on the Internet: Timestamps July 2002
341
342
3435.3. Rarely Used Options
344
345 A format which includes rarely used options is likely to cause
346 interoperability problems. This is because rarely used options are
347 less likely to be used in alpha or beta testing, so bugs in parsing
348 are less likely to be discovered. Rarely used options should be made
349 mandatory or omitted for the sake of interoperability whenever
350 possible.
351
352 The format defined below includes only one rarely used option:
353 fractions of a second. It is expected that this will be used only by
354 applications which require strict ordering of date/time stamps or
355 which have an unusual precision requirement.
356
3575.4. Redundant Information
358
359 If a date/time format includes redundant information, that introduces
360 the possibility that the redundant information will not correlate.
361 For example, including the day of the week in a date/time format
362 introduces the possibility that the day of week is incorrect but the
363 date is correct, or vice versa. Since it is not difficult to compute
364 the day of week from a date (see Appendix B), the day of week should
365 not be included in a date/time format.
366
3675.5. Simplicity
368
369 The complete set of date and time formats specified in ISO 8601
370 [ISO8601] is quite complex in an attempt to provide multiple
371 representations and partial representations. Appendix A contains an
372 attempt to translate the complete syntax of ISO 8601 into ABNF.
373 Internet protocols have somewhat different requirements and
374 simplicity has proved to be an important characteristic. In
375 addition, Internet protocols usually need complete specification of
376 data in order to achieve true interoperability. Therefore, the
377 complete grammar for ISO 8601 is deemed too complex for most Internet
378 protocols.
379
380 The following section defines a profile of ISO 8601 for use on the
381 Internet. It is a conformant subset of the ISO 8601 extended format.
382 Simplicity is achieved by making most fields and punctuation
383 mandatory.
384
385
386
387
388
389
390
391
392
393
394Klyne, et. al. Standards Track [Page 7]
395
396RFC 3339 Date and Time on the Internet: Timestamps July 2002
397
398
3995.6. Internet Date/Time Format
400
401 The following profile of ISO 8601 [ISO8601] dates SHOULD be used in
402 new protocols on the Internet. This is specified using the syntax
403 description notation defined in [ABNF].
404
405 date-fullyear = 4DIGIT
406 date-month = 2DIGIT ; 01-12
407 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
408 ; month/year
409 time-hour = 2DIGIT ; 00-23
410 time-minute = 2DIGIT ; 00-59
411 time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second
412 ; rules
413 time-secfrac = "." 1*DIGIT
414 time-numoffset = ("+" / "-") time-hour ":" time-minute
415 time-offset = "Z" / time-numoffset 8460:682 ../tlsrpt/report.go:200
416
417 partial-time = time-hour ":" time-minute ":" time-second
418 [time-secfrac]
419 full-date = date-fullyear "-" date-month "-" date-mday
420 full-time = partial-time time-offset
421
422 date-time = full-date "T" full-time
423
424 NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in this
425 syntax may alternatively be lower case "t" or "z" respectively.
426
427 This date/time format may be used in some environments or contexts
428 that distinguish between the upper- and lower-case letters 'A'-'Z'
429 and 'a'-'z' (e.g. XML). Specifications that use this format in
430 such environments MAY further limit the date/time syntax so that
431 the letters 'T' and 'Z' used in the date/time syntax must always
432 be upper case. Applications that generate this format SHOULD use
433 upper case letters.
434
435 NOTE: ISO 8601 defines date and time separated by "T".
436 Applications using this syntax may choose, for the sake of
437 readability, to specify a full-date and full-time separated by
438 (say) a space character.
439
440
441
442
443
444
445
446
447
448
449
450Klyne, et. al. Standards Track [Page 8]
451
452RFC 3339 Date and Time on the Internet: Timestamps July 2002
453
454
4555.7. Restrictions
456
457 The grammar element date-mday represents the day number within the
458 current month. The maximum value varies based on the month and year
459 as follows:
460
461 Month Number Month/Year Maximum value of date-mday
462 ------------ ---------- --------------------------
463 01 January 31
464 02 February, normal 28
465 02 February, leap year 29
466 03 March 31
467 04 April 30
468 05 May 31
469 06 June 30
470 07 July 31
471 08 August 31
472 09 September 30
473 10 October 31
474 11 November 30
475 12 December 31
476
477 Appendix C contains sample C code to determine if a year is a leap
478 year.
479
480 The grammar element time-second may have the value "60" at the end of
481 months in which a leap second occurs -- to date: June (XXXX-06-
482 30T23:59:60Z) or December (XXXX-12-31T23:59:60Z); see Appendix D for
483 a table of leap seconds. It is also possible for a leap second to be
484 subtracted, at which times the maximum value of time-second is "58".
485 At all other times the maximum value of time-second is "59".
486 Further, in time zones other than "Z", the leap second point is
487 shifted by the zone offset (so it happens at the same instant around
488 the globe).
489
490 Leap seconds cannot be predicted far into the future. The
491 International Earth Rotation Service publishes bulletins [IERS] that
492 announce leap seconds with a few weeks' warning. Applications should
493 not generate timestamps involving inserted leap seconds until after
494 the leap seconds are announced.
495
496 Although ISO 8601 permits the hour to be "24", this profile of ISO
497 8601 only allows values between "00" and "23" for the hour in order
498 to reduce confusion.
499
500
501
502
503
504
505
506Klyne, et. al. Standards Track [Page 9]
507
508RFC 3339 Date and Time on the Internet: Timestamps July 2002
509
510
5115.8. Examples
512
513 Here are some examples of Internet date/time format.
514
515 1985-04-12T23:20:50.52Z
516
517 This represents 20 minutes and 50.52 seconds after the 23rd hour of
518 April 12th, 1985 in UTC.
519
520 1996-12-19T16:39:57-08:00
521
522 This represents 39 minutes and 57 seconds after the 16th hour of
523 December 19th, 1996 with an offset of -08:00 from UTC (Pacific
524 Standard Time). Note that this is equivalent to 1996-12-20T00:39:57Z
525 in UTC.
526
527 1990-12-31T23:59:60Z
528
529 This represents the leap second inserted at the end of 1990.
530
531 1990-12-31T15:59:60-08:00
532
533 This represents the same leap second in Pacific Standard Time, 8
534 hours behind UTC.
535
536 1937-01-01T12:00:27.87+00:20
537
538 This represents the same instant of time as noon, January 1, 1937,
539 Netherlands time. Standard time in the Netherlands was exactly 19
540 minutes and 32.13 seconds ahead of UTC by law from 1909-05-01 through
541 1937-06-30. This time zone cannot be represented exactly using the
542 HH:MM format, and this timestamp uses the closest representable UTC
543 offset.
544
5456. References
546
547 [ZELLER] Zeller, C., "Kalender-Formeln", Acta Mathematica, Vol.
548 9, Nov 1886.
549
550 [IMAIL] Crocker, D., "Standard for the Format of Arpa Internet
551 Text Messages", STD 11, RFC 822, August 1982.
552
553 [IMAIL-UPDATE] Resnick, P., "Internet Message Format", RFC 2822,
554 April 2001.
555
556 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
557 Specifications: ABNF", RFC 2234, November 1997.
558
559
560
561
562Klyne, et. al. Standards Track [Page 10]
563
564RFC 3339 Date and Time on the Internet: Timestamps July 2002
565
566
567 [ISO8601] "Data elements and interchange formats -- Information
568 interchange -- Representation of dates and times", ISO
569 8601:1988(E), International Organization for
570 Standardization, June, 1988.
571
572 [ISO8601:2000] "Data elements and interchange formats -- Information
573 interchange -- Representation of dates and times", ISO
574 8601:2000, International Organization for
575 Standardization, December, 2000.
576
577 [HOST-REQ] Braden, R., "Requirements for Internet Hosts --
578 Application and Support", STD 3, RFC 1123, October
579 1989.
580
581 [IERS] International Earth Rotation Service Bulletins,
582 <http://hpiers.obspm.fr/eop-
583 pc/products/bulletins.html>.
584
585 [NTP] Mills, D, "Network Time Protocol (Version 3)
586 Specification, Implementation and Analysis", RFC 1305,
587 March 1992.
588
589 [ITU-R-TF] International Telecommunication Union Recommendations
590 for Time Signals and Frequency Standards Emissions.
591 <http://www.itu.ch/publications/itu-r/iturtf.htm>
592
593 [RFC2119] Bradner, S, "Key words for use in RFCs to Indicate
594 Requirement Levels", BCP 14, RFC 2119, March 1997.
595
5967. Security Considerations
597
598 Since the local time zone of a site may be useful for determining a
599 time when systems are less likely to be monitored and might be more
600 susceptible to a security probe, some sites may wish to emit times in
601 UTC only. Others might consider this to be loss of useful
602 functionality at the hands of paranoia.
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618Klyne, et. al. Standards Track [Page 11]
619
620RFC 3339 Date and Time on the Internet: Timestamps July 2002
621
622
623Appendix A. ISO 8601 Collected ABNF
624
625 This information is based on the 1988 version of ISO 8601. There may
626 be some changes in the 2000 revision.
627
628 ISO 8601 does not specify a formal grammar for the date and time
629 formats it defines. The following is an attempt to create a formal
630 grammar from ISO 8601. This is informational only and may contain
631 errors. ISO 8601 remains the authoritative reference.
632
633 Note that due to ambiguities in ISO 8601, some interpretations had to
634 be made. First, ISO 8601 is not clear if mixtures of basic and
635 extended format are permissible. This grammar permits mixtures. ISO
636 8601 is not clear on whether an hour of 24 is permissible only if
637 minutes and seconds are 0. This assumes that an hour of 24 is
638 permissible in any context. Restrictions on date-mday in section 5.7
639 apply. ISO 8601 states that the "T" may be omitted under some
640 circumstances. This grammar requires the "T" to avoid ambiguity.
641 ISO 8601 also requires (in section 5.3.1.3) that a decimal fraction
642 be proceeded by a "0" if less than unity. Annex B.2 of ISO 8601
643 gives examples where the decimal fractions are not preceded by a "0".
644 This grammar assumes section 5.3.1.3 is correct and that Annex B.2 is
645 in error.
646
647 date-century = 2DIGIT ; 00-99
648 date-decade = DIGIT ; 0-9
649 date-subdecade = DIGIT ; 0-9
650 date-year = date-decade date-subdecade
651 date-fullyear = date-century date-year
652 date-month = 2DIGIT ; 01-12
653 date-wday = DIGIT ; 1-7 ; 1 is Monday, 7 is Sunday
654 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
655 ; month/year
656 date-yday = 3DIGIT ; 001-365, 001-366 based on year
657 date-week = 2DIGIT ; 01-52, 01-53 based on year
658
659 datepart-fullyear = [date-century] date-year ["-"]
660 datepart-ptyear = "-" [date-subdecade ["-"]]
661 datepart-wkyear = datepart-ptyear / datepart-fullyear
662
663 dateopt-century = "-" / date-century
664 dateopt-fullyear = "-" / datepart-fullyear
665 dateopt-year = "-" / (date-year ["-"])
666 dateopt-month = "-" / (date-month ["-"])
667 dateopt-week = "-" / (date-week ["-"])
668
669
670
671
672
673
674Klyne, et. al. Standards Track [Page 12]
675
676RFC 3339 Date and Time on the Internet: Timestamps July 2002
677
678
679 datespec-full = datepart-fullyear date-month ["-"] date-mday
680 datespec-year = date-century / dateopt-century date-year
681 datespec-month = "-" dateopt-year date-month [["-"] date-mday]
682 datespec-mday = "--" dateopt-month date-mday
683 datespec-week = datepart-wkyear "W"
684 (date-week / dateopt-week date-wday)
685 datespec-wday = "---" date-wday
686 datespec-yday = dateopt-fullyear date-yday
687
688 date = datespec-full / datespec-year
689 / datespec-month /
690 datespec-mday / datespec-week / datespec-wday / datespec-yday
691
692Time:
693
694 time-hour = 2DIGIT ; 00-24
695 time-minute = 2DIGIT ; 00-59
696 time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on
697 ; leap-second rules
698 time-fraction = ("," / ".") 1*DIGIT
699 time-numoffset = ("+" / "-") time-hour [[":"] time-minute]
700 time-zone = "Z" / time-numoffset
701
702 timeopt-hour = "-" / (time-hour [":"])
703 timeopt-minute = "-" / (time-minute [":"])
704
705 timespec-hour = time-hour [[":"] time-minute [[":"] time-second]]
706 timespec-minute = timeopt-hour time-minute [[":"] time-second]
707 timespec-second = "-" timeopt-minute time-second
708 timespec-base = timespec-hour / timespec-minute / timespec-second
709
710 time = timespec-base [time-fraction] [time-zone]
711
712 iso-date-time = date "T" time
713
714Durations:
715
716 dur-second = 1*DIGIT "S"
717 dur-minute = 1*DIGIT "M" [dur-second]
718 dur-hour = 1*DIGIT "H" [dur-minute]
719 dur-time = "T" (dur-hour / dur-minute / dur-second)
720 dur-day = 1*DIGIT "D"
721 dur-week = 1*DIGIT "W"
722 dur-month = 1*DIGIT "M" [dur-day]
723 dur-year = 1*DIGIT "Y" [dur-month]
724 dur-date = (dur-day / dur-month / dur-year) [dur-time]
725
726 duration = "P" (dur-date / dur-time / dur-week)
727
728
729
730Klyne, et. al. Standards Track [Page 13]
731
732RFC 3339 Date and Time on the Internet: Timestamps July 2002
733
734
735Periods:
736
737 period-explicit = iso-date-time "/" iso-date-time
738 period-start = iso-date-time "/" duration
739 period-end = duration "/" iso-date-time
740
741 period = period-explicit / period-start / period-end
742
743Appendix B. Day of the Week
744
745 The following is a sample C subroutine loosely based on Zeller's
746 Congruence [Zeller] which may be used to obtain the day of the week
747 for dates on or after 0000-03-01:
748
749 char *day_of_week(int day, int month, int year)
750 {
751 int cent;
752 char *dayofweek[] = {
753 "Sunday", "Monday", "Tuesday", "Wednesday",
754 "Thursday", "Friday", "Saturday"
755 };
756
757 /* adjust months so February is the last one */
758 month -= 2;
759 if (month < 1) {
760 month += 12;
761 --year;
762 }
763 /* split by century */
764 cent = year / 100;
765 year %= 100;
766 return (dayofweek[((26 * month - 2) / 10 + day + year
767 + year / 4 + cent / 4 + 5 * cent) % 7]);
768 }
769
770Appendix C. Leap Years
771
772 Here is a sample C subroutine to calculate if a year is a leap year:
773
774 /* This returns non-zero if year is a leap year. Must use 4 digit
775 year.
776 */
777 int leap_year(int year)
778 {
779 return (year % 4 == 0 && (year % 100 != 0 || year % 400 == 0));
780 }
781
782
783
784
785
786Klyne, et. al. Standards Track [Page 14]
787
788RFC 3339 Date and Time on the Internet: Timestamps July 2002
789
790
791Appendix D. Leap Seconds
792
793 Information about leap seconds can be found at:
794 <http://tycho.usno.navy.mil/leapsec.html>. In particular, it notes
795 that:
796
797 The decision to introduce a leap second in UTC is the
798 responsibility of the International Earth Rotation Service (IERS).
799 According to the CCIR Recommendation, first preference is given to
800 the opportunities at the end of December and June, and second
801 preference to those at the end of March and September.
802
803 When required, insertion of a leap second occurs as an extra second
804 at the end of a day in UTC, represented by a timestamp of the form
805 YYYY-MM-DDT23:59:60Z. A leap second occurs simultaneously in all
806 time zones, so that time zone relationships are not affected. See
807 section 5.8 for some examples of leap second times.
808
809 The following table is an excerpt from the table maintained by the
810 United States Naval Observatory. The source data is located at:
811
812 <ftp://maia.usno.navy.mil/ser7/tai-utc.dat>
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
842Klyne, et. al. Standards Track [Page 15]
843
844RFC 3339 Date and Time on the Internet: Timestamps July 2002
845
846
847 This table shows the date of the leap second, and the difference
848 between the time standard TAI (which isn't adjusted by leap seconds)
849 and UTC after that leap second.
850
851 UTC Date TAI - UTC After Leap Second
852 -------- ---------------------------
853 1972-06-30 11
854 1972-12-31 12
855 1973-12-31 13
856 1974-12-31 14
857 1975-12-31 15
858 1976-12-31 16
859 1977-12-31 17
860 1978-12-31 18
861 1979-12-31 19
862 1981-06-30 20
863 1982-06-30 21
864 1983-06-30 22
865 1985-06-30 23
866 1987-12-31 24
867 1989-12-31 25
868 1990-12-31 26
869 1992-06-30 27
870 1993-06-30 28
871 1994-06-30 29
872 1995-12-31 30
873 1997-06-30 31
874 1998-12-31 32
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898Klyne, et. al. Standards Track [Page 16]
899
900RFC 3339 Date and Time on the Internet: Timestamps July 2002
901
902
903Acknowledgements
904
905 The following people provided helpful advice for an earlier
906 incarnation of this document: Ned Freed, Neal McBurnett, David
907 Keegel, Markus Kuhn, Paul Eggert and Robert Elz. Thanks are also due
908 to participants of the IETF Calendaring/Scheduling working group
909 mailing list, and participants of the time zone mailing list.
910
911 The following reviewers contributed helpful suggestions for the
912 present revision: Tom Harsch, Markus Kuhn, Pete Resnick, Dan Kohn.
913 Paul Eggert provided many careful observations regarding the
914 subtleties of leap seconds and time zone offsets. The following
915 people noted corrections and improvements to earlier drafts: Dr John
916 Stockton, Jutta Degener, Joe Abley, and Dan Wing.
917
918Authors' Addresses
919
920 Chris Newman
921 Sun Microsystems
922 1050 Lakes Drive, Suite 250
923 West Covina, CA 91790 USA
924
925 EMail: chris.newman@sun.com
926
927
928 Graham Klyne (editor, this revision)
929 Clearswift Corporation
930 1310 Waterside
931 Arlington Business Park
932 Theale, Reading RG7 4SA
933 UK
934
935 Phone: +44 11 8903 8903
936 Fax: +44 11 8903 9000
937 EMail: GK@ACM.ORG
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954Klyne, et. al. Standards Track [Page 17]
955
956RFC 3339 Date and Time on the Internet: Timestamps July 2002
957
958
959Full Copyright Statement
960
961 Copyright (C) The Internet Society (2002). All Rights Reserved.
962
963 This document and translations of it may be copied and furnished to
964 others, and derivative works that comment on or otherwise explain it
965 or assist in its implementation may be prepared, copied, published
966 and distributed, in whole or in part, without restriction of any
967 kind, provided that the above copyright notice and this paragraph are
968 included on all such copies and derivative works. However, this
969 document itself may not be modified in any way, such as by removing
970 the copyright notice or references to the Internet Society or other
971 Internet organizations, except as needed for the purpose of
972 developing Internet standards in which case the procedures for
973 copyrights defined in the Internet Standards process must be
974 followed, or as required to translate it into languages other than
975 English.
976
977 The limited permissions granted above are perpetual and will not be
978 revoked by the Internet Society or its successors or assigns.
979
980 This document and the information contained herein is provided on an
981 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
982 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
983 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
984 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
985 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
986
987Acknowledgement
988
989 Funding for the RFC Editor function is currently provided by the
990 Internet Society.
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010Klyne, et. al. Standards Track [Page 18]
1011
1012