< draft-ietf-sedate-datetime-extended-03.txt   draft-ietf-sedate-datetime-extended-04.txt >
Serialising Extended Data About Times and Events U. Sharma Serialising Extended Data About Times and Events U. Sharma
Internet-Draft Igalia, S.L. Internet-Draft Igalia, S.L.
Intended status: Standards Track C. Bormann Intended status: Standards Track C. Bormann
Expires: 9 September 2022 Universität Bremen TZI Expires: 22 September 2022 Universität Bremen TZI
8 March 2022 21 March 2022
Date and Time on the Internet: Timestamps with additional information Date and Time on the Internet: Timestamps with additional information
draft-ietf-sedate-datetime-extended-03 draft-ietf-sedate-datetime-extended-04
Abstract Abstract
This document defines an extension to the timestamp format defined in This document defines an extension to the timestamp format defined in
RFC3339 for representing additional information including a time RFC3339 for representing additional information including a time
zone. zone.
About This Document About This Document
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 9 September 2022. This Internet-Draft will expire on 22 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Extended Date/Time format . . . . . . . . . . . . . . . . . . 5 2. Extended Date/Time format . . . . . . . . . . . . . . . . . . 6
2.1. Informative . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Informative . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Registered . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Registered . . . . . . . . . . . . . . . . . . . . . . . 7
3. Syntax Extensions to RFC 3339 . . . . . . . . . . . . . . . . 6 3. Syntax Extensions to RFC 3339 . . . . . . . . . . . . . . . . 7
3.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Dates and times are used in a very diverse set of internet Dates and times are used in a very diverse set of internet
applications, all the way from server-side logging to calendaring and applications, all the way from server-side logging to calendaring and
scheduling. scheduling.
Each distinct instant in time can be represented in a descriptive Each distinct instant in time can be represented in a descriptive
text format using a timestamp, and [ISO8601] standardizes a widely- text format using a timestamp, and [ISO8601:1988] standardizes a
adopted timestamp format, which forms the basis of [RFC3339]. widely-adopted timestamp format, which forms the basis of [RFC3339].
However, this format only allows timestamps to contain very little However, this format only allows timestamps to contain very little
additional relevant information, which means that, beyond that, any additional relevant information, which means that, beyond that, any
contextual information related to a given timestamp needs to be contextual information related to a given timestamp needs to be
either handled separately or attached to it in a non-standard manner. either handled separately or attached to it in a non-standard manner.
This is already a pressing issue for applications that handle each This is already a pressing issue for applications that handle each
instant with an associated time zone name, to take into account instant with an associated time zone name, to take into account
events such as daylight saving time transitions. Most of these events such as daylight saving time transitions. Most of these
applications attach the time zone to the timestamp in a non-standard applications attach the time zone to the timestamp in a non-standard
format, at least one of which is fairly well-adopted [JAVAZDT]. format, at least one of which is fairly well-adopted [JAVAZDT].
skipping to change at page 4, line 47 skipping to change at page 5, line 10
ABNF: Augmented Backus-Naur Form, a format used to represent ABNF: Augmented Backus-Naur Form, a format used to represent
permissible strings in a protocol or language, as defined in permissible strings in a protocol or language, as defined in
[RFC5234]. The rules defined in Appendix B of [RFC5234] are [RFC5234]. The rules defined in Appendix B of [RFC5234] are
imported implicitly. imported implicitly.
Internet Date/Time Format: The date/time format defined in section 3 Internet Date/Time Format: The date/time format defined in section 3
of this document. of this document.
Timestamp: An unambiguous representation of some instant in time. Timestamp: An unambiguous representation of some instant in time.
UTC Offset: Difference between a given local time and UTC, usually
given in negative or positive hours and minutes. For example,
local time in New York in the wintertime is 5 hours behind UTC, so
its UTC offset is "-05:00".
Z: A suffix which, when applied to a time, denotes a UTC offset of Z: A suffix which, when applied to a time, denotes a UTC offset of
00:00; often spoken "Zulu" from the ICAO phonetic alphabet 00:00; often spoken "Zulu" from the ICAO phonetic alphabet
representation of the letter "Z" (from Section 2 of [RFC3339]). representation of the letter "Z". (Definition from Section 2 of
[RFC3339].)
Time Zone: A time zone that is included in the Time Zone Database Time Zone: A set of rules representing the relationship of local
(often called tz or zoneinfo) maintained by IANA. time to UTC for a particular place or region. Mathematically, a
time zone can be thought of as a function that maps timestamps to
UTC offsets. Time zones can deterministically convert a timestamp
to local time. They can also be used in the reverse direction to
convert local time to a timestamp, with the caveat that some local
times may have zero or multiple possible timestamps due to nearby
Daylight Saving Time changes or other changes to the UTC offset of
that time zone. Unlike the UTC offset of a timestamp which makes
no claims about the UTC offset of other related timestamps (and
which is therefore unsuitable for performing local-time operations
such as "one day later"), a time zone also defines how to derive
new timestamps based on differences in local time. For example,
to calculate "one day later than this timestamp in San Francisco",
a time zone is required because the UTC offset of local time in
San Francisco can change from one day to the next.
IANA Time Zone: A named time zone that is included in the Time Zone
Database (often called tz or zoneinfo) maintained by IANA
[TZDB][BCP175]. Most IANA time zones are named for the largest
city in a particular region that shares the same time zone rules,
e.g. Europe/Paris or Asia/Tokyo [TZDB-NAMING]. Special IANA time
zones such as Etc/GMT+10 can be used to represent timestamps
outside country boundaries, e.g. a buoy in the middle of the
Pacific Ocean (note that the Etc/GMT+10 time zone has a constant
UTC Offset of -10:00 [sic!]).
Note that the rules defined for a named IANA time zone can change
over time. The use of a named IANA time zone implies that the
intent is for the rules that are current at the time of
interpretation to apply, i.e., the additional information conveyed
by using that time zone name is to change with the changed rules
as recorded in the IANA time zone database.
Offset Time Zone: A time zone defined by a specific UTC offset, e.g.
+08:45 and serialized using as its name the same numeric UTC
offset format used in an RFC 3339 timestamp. Although
serialization with offset time zones is supported in this document
for backwards compatibility with java.time.ZonedDateTime
[JAVAZDT], use of offset time zones is strongly discouraged. In
particular, programs MUST NOT copy the UTC offset from a timestamp
into an offset time zone in order to satisfy another program which
requires a time zone annotation in its input. Doing this will
improperly assert that the UTC offset of timestamps in that
location will never change, which can result in incorrect
calculations in programs that add, subtract, or otherwise derive
new timestamps from the one provided. For example, 2020-01-
01T00:00+01:00[Europe/Paris] will let programs add six months to
the timestamp while adjusting for Summer Time (Daylight Saving
Time). But the same calculation applied to
2020-01-01T00:00+01:00[+01:00] will produce an incorrect result
that will be off by one hour in the timezone Europe/Paris.
CLDR: Common locale data repository [CLDR], a project of the Unicode CLDR: Common locale data repository [CLDR], a project of the Unicode
Consortium to provide locale data to applications. Consortium to provide locale data to applications.
For more information about time scales, see Appendix E of [RFC1305], For more information about time scales, see Appendix E of [RFC1305],
Section 3 of [ISO8601], and the appropriate ITU documents Section 3 of [ISO8601:1988], and the appropriate ITU documents
[ITU-R-TF.460-6]. [ITU-R-TF.460-6].
2. Extended Date/Time format 2. Extended Date/Time format
This section discusses desirable qualities of formats for the This section discusses desirable qualities of formats for the
timestamp extension suffix and defines such a format that extends timestamp extension suffix and defines such a format that extends
[RFC3339] for use in Internet protocols. [RFC3339] for use in Internet protocols.
2.1. Informative 2.1. Informative
skipping to change at page 6, line 31 skipping to change at page 8, line 6
leaking out to general production and why that MUST be prevented. leaking out to general production and why that MUST be prevented.
3. Syntax Extensions to RFC 3339 3. Syntax Extensions to RFC 3339
3.1. ABNF 3.1. ABNF
The following rules extend the ABNF syntax defined in [RFC3339] in The following rules extend the ABNF syntax defined in [RFC3339] in
order to allow the inclusion of an optional suffix. order to allow the inclusion of an optional suffix.
The extended date/time format is described by the rule date-time-ext. The extended date/time format is described by the rule date-time-ext.
date-time is imported from Section 5.6 of [RFC3339], ALPHA and DIGIT date-time and time-numoffset are imported from Section 5.6 of
from Appendix B.1 of [RFC5234]. [RFC3339], ALPHA and DIGIT from Appendix B.1 of [RFC5234].
time-zone-initial = ALPHA / "." / "_" time-zone-initial = ALPHA / "." / "_"
time-zone-char = time-zone-initial / DIGIT / "-" / "+" time-zone-char = time-zone-initial / DIGIT / "-" / "+"
time-zone-part = time-zone-initial *13(time-zone-char) time-zone-part = time-zone-initial *13(time-zone-char)
; but not "." or ".." ; but not "." or ".."
time-zone-name = time-zone-part *("/" time-zone-part) time-zone-name = time-zone-part *("/" time-zone-part)
time-zone = "[" time-zone-name "]" time-zone = "[" time-zone-name / time-numoffset "]"
key-initial = ALPHA / "_" key-initial = ALPHA / "_"
key-char = key-initial / DIGIT / "-" key-char = key-initial / DIGIT / "-"
suffix-key = key-initial *key-char suffix-key = key-initial *key-char
suffix-value = 1*alphanum suffix-value = 1*alphanum
suffix-values = suffix-value *("-" suffix-value) suffix-values = suffix-value *("-" suffix-value)
suffix-tag = "[" suffix-key "=" suffix-values "]" suffix-tag = "[" suffix-key "=" suffix-values "]"
suffix = [time-zone] *suffix-tag suffix = [time-zone] *suffix-tag
skipping to change at page 8, line 26 skipping to change at page 9, line 49
specification does exist, even if not complete or published yet. specification does exist, even if not complete or published yet.
5. Security Considerations 5. Security Considerations
TBD TBD
6. References 6. References
6.1. Normative References 6.1. Normative References
[BCP175] Lear, E. and P. Eggert, "Procedures for Maintaining the
Time Zone Database", BCP 175, RFC 6557,
DOI 10.17487/RFC6557, February 2012,
<https://www.rfc-editor.org/info/rfc6557>.
[BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham, [BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham,
"Deprecating the "X-" Prefix and Similar Constructs in "Deprecating the "X-" Prefix and Similar Constructs in
Application Protocols", BCP 178, RFC 6648, June 2012. Application Protocols", BCP 178, RFC 6648,
DOI 10.17487/RFC6648, June 2012,
<https://www.rfc-editor.org/info/bcp178> <https://www.rfc-editor.org/info/rfc6648>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>. <https://www.rfc-editor.org/info/rfc3339>.
skipping to change at page 9, line 22 skipping to change at page 10, line 47
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
6.2. Informative References 6.2. Informative References
[CLDR] "Unicode CLDR Project", <https://cldr.unicode.org>. [CLDR] "Unicode CLDR Project", <https://cldr.unicode.org>.
[IERS] "International Earth Rotation Service Bulletins", [IERS] "International Earth Rotation Service Bulletins",
<https://www.iers.org/IERS/EN/Publications/Bulletins/ <https://www.iers.org/IERS/EN/Publications/Bulletins/
bulletins.html>. bulletins.html>.
[ISO8601] International Organization for Standardization, "Data [ISO8601:1988]
International Organization for Standardization, "Data
elements and interchange formats — Information interchange elements and interchange formats — Information interchange
— Representation of dates and times", ISO 8601:1988, June — Representation of dates and times", ISO 8601:1988, June
1988, <https://www.iso.org/standard/15903.html>. 1988, <https://www.iso.org/standard/15903.html>.
[ITU-R-TF.460-6] [ITU-R-TF.460-6]
"ITU-R TF.460-6. Standard-frequency and time-signal "ITU-R TF.460-6. Standard-frequency and time-signal
emissions", February 2002, emissions", February 2002,
<https://www.itu.int/rec/R-REC-TF.460/en>. <https://www.itu.int/rec/R-REC-TF.460/en>.
[JAVAZDT] "Java SE 8, java.time.format, DateTimeFormatter: [JAVAZDT] "Java SE 8, java.time.format, DateTimeFormatter:
ISO_ZONED_DATE_TIME", ISO_ZONED_DATE_TIME",
<https://docs.oracle.com/javase/8/docs/api/java/time/ <https://docs.oracle.com/javase/8/docs/api/java/time/
format/DateTimeFormatter.html#ISO_ZONED_DATE_TIME>. format/DateTimeFormatter.html#ISO_ZONED_DATE_TIME>.
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC 1305, Specification, Implementation and Analysis", RFC 1305,
DOI 10.17487/RFC1305, March 1992, DOI 10.17487/RFC1305, March 1992,
<https://www.rfc-editor.org/info/rfc1305>. <https://www.rfc-editor.org/info/rfc1305>.
[TZDB] "Sources for time zone and daylight saving time data",
<https://data.iana.org/time-zones/tz-link.html>.
[TZDB-NAMING]
"Theory and pragmatics of the tz code and data",
<https://data.iana.org/time-zones/theory.html>.
Acknowledgements Acknowledgements
Richard Gibson provided some editorial improvements. Richard Gibson provided some editorial improvements.
Contributors
Justin Grant
Email: justingrant.ietf.public@gmail.com
Your Name Here
Authors' Addresses Authors' Addresses
Ujjwal Sharma Ujjwal Sharma
Igalia, S.L. Igalia, S.L.
Bugallal Marchesi, 22, 1º Bugallal Marchesi, 22, 1º
15008 A Coruña 15008 A Coruña
Spain Spain
Email: ryzokuken@igalia.com Email: ryzokuken@igalia.com
Carsten Bormann Carsten Bormann
Universität Bremen TZI Universität Bremen TZI
Postfach 330440 Postfach 330440
D-28359 Bremen D-28359 Bremen
Germany Germany
Phone: +49-421-218-63921 Phone: +49-421-218-63921
Email: cabo@tzi.org Email: cabo@tzi.org
 End of changes. 17 change blocks. 
31 lines changed or deleted 107 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/