Network Working Group C. Newman
Internet Draft: Date and Time on the Internet Innosoft
Document: draft-newman-datetime-00.txt December 1996
Date and Time on the Internet
Status of this memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress``.
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
munnari.oz.au.
A revised version of this draft document will be submitted to the
IESG as a Proposed Standard for the Internet Community. Discussion
and suggestions for improvement are requested. This document will
expire six months after publication. Distribution of this draft is
unlimited.
1. Introduction
Date and time formats cause a lot of confusion and interoperability
problems on the Internet. This document will address many of the
problems encountered and make recommendations to improve
consistancy and interoperability when representing and using date
and time in Internet protocols.
This document includes an Internet profile of the ISO 8601
[ISO8601] standard for representation of dates and times.
[More detail work is needed, but I wanted to get this out before I
go on vacation to see if it meets the basic requirements coming
from the ASID and CALSCH working groups. Places needing work are
Newman [Page 1]
Internet Draft Date and Time December 1996
marked with XXX]
2. Definitions
UTC Coordinated Universal Time as maintained by the Bureau
Internaational de l'Heure (International Time Bureau).
[XXX definitely need more definitions here. It would be nice to
reference a good time standard to define seconds, leap years, etc.]
3. Two or Three Digit Years
Two digit years are expected to cause great expense to many as the
year 2000 approaches. Many existing computer programs simply add
or subtract 1900 from a two digit year. Such programs will clearly
stop functioning on the year 2000 and will have to be upgraded,
possibly at great expense [XXX - ref to Wall Street Journal article
on IRS year 2000 problems would be cool]. The following
requirements are made of Internet protocols to address this
problem:
o Internet Protocols MUST generate four digit years in dates.
o If a two digit year is received, the values 00-49 SHOULD be
interpreted as referring to the 21st century (add 2000) and the
values 50-99 SHOULD be interpreted as referring to the 20th century
(add 1900).
o Three digit years MUST be interpreted by adding 1900.
4. Local Time
4.1. Coordinated Universal Time (UTC)
Because the daylight rules for local timezones are so convoluted
[XXX-ref], true interoperability is best achieved by using
Coordinated Universal Time (UTC) [XXX-ref].
4.2. Local Offsets
The offset between local time and UTC is often useful information.
For example, in electronic mail [IMAIL] the local offset provides a
useful heuristic to determine the probability of a prompt response.
Attempts to label local offsets with alphabetic strings have met
with poor interoperability results in the past [IMAIL], [HOST-REQ].
Newman [Page 2]
Internet Draft Date and Time December 1996
Therefore numeric offsets are now REQUIRED. When the local offset
is unknown, the offset "-00:00" MAY be used to indicate that the
time is in UTC and the local offset is unknown.
4.3. Unqualified Local Time
A number of devices currently connected to the Internet run their
internal clocks in local time and are unaware of UTC. While the
Internet does have a tradition of accepting reality when creating
specifications, this should not be done at the expense of
interoperability. Since interpretation of an unqualified local
timezone will fail in approximately 23/24 of the globe, the
interoperability problems of unqualified local time are deemed
unacceptable for the Internet. Devices which are unaware of the
time in UTC MUST use one of the following techniques when
communicating on the Internet:
o Use Network Time Protocol [NTP] to obtain the time in UTC.
o Use another host in the same local timezone as a gateway to the
Internet. This host MUST correct unqualified local times before
they are transmitted to other hosts.
o Prompt the user for the local timezone if it is aware of the
daylight rules. One technique to do this is by having the user
select a major city in their timezone. An alternative would be to
show a list of the timezone labels defined in [section XXX].
5. Date and Time formats
The date and time format defined in [IMAIL] and as amended by
[HOST-REQ] may be referred to as "the Internet Mail Date/Time
Format". The profile of ISO 8601 defined in this section may be
referred to as "the Internet Date/Time Format". The following
sections describe useful properties of a date and time format for
interchange on the Internet.
5.1. Ordering
If date and time components are ordered from least precise to most
precise, then a useful property is achieved. Assuming that the
timezones of the dates and times are the same (e.g. all in UTC),
then the date and time strings may be sorted as strings (e.g. using
the strcmp() function in C) and a time-ordered sequence will
result. The presence of optional punctuation would violate this
Newman [Page 3]
Internet Draft Date and Time December 1996
characteristic.
5.2. Human Readability
Human readability has proved to be a valuable feature of Internet
protocols. Human readable protocols greatly reduce the costs of
debugging since telnet often suffices as a test client and network
analysers need not be modified with knowledge of the protocol. On
the other hand, human readability sometimes results in
interoperability problems. For example, the date format
"10/11/1996" is completely unsuitable for global interchange
because it is interpreted differently in different countries. In
addition, the date format in [IMAIL] has resulted in
interoperability problems when people assumed it was simply a text
string and translated the three letter abbreviations to other
languages or substituted date formats which were easier to generate
(e.g. the format used by the C function ctime). For this reason, a
balance must be struck between human readability and
interoperability.
Because no date and time format is readable according to the
conventions of all countries, Internet clients SHOULD be prepared
to transform dates into a display format suitable for the locality.
This includes translating UTC to local time.
5.3. Simplicity
The complete set of date and time formats specified in ISO 8601
[ISO8601] is quite complex in an attempt to provide multiple
representations and partial representations. Appendix A contains
an attempt to translate the complete syntax of ISO 8601 into ABNF
as defined in [IMAIL]. Internet protocols have somewhat different
requirements and simplicity has proved to be an important
characteristic. In addition, Internet protocols usually need
complete specification of data in order to achieve true
interoperability. Therefore, the complete grammar for ISO 8601 is
deemed too complex for most Internet protocols.
The following section defines an profile of ISO 8601 for use on the
Internet. It is a conformant subset of the ISO 8601 extended
format. Simplicity is achieved by making most fields and
punctuation mandatory.
5.4. Internet Date/Time Format
Newman [Page 4]
Internet Draft Date and Time December 1996
The following profile of ISO 8601 [ISO8601] dates SHOULD be used in
new protocols on the Internet. This is specified using ABNF as
defined in [IMAIL].
date-fullyear = 4DIGIT
date-month = 2DIGIT ; 01-12
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on month/year
time-hour = 2DIGIT ; 00-24
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-60
time-secfrac = "," 1*DIGIT
time-numzone = ("+" / "-") time-hour ":" time-minute
time-zone = "Z" / time-numzone
full-date = date-fullyear "-" date-month "-" date-mday
full-time = time-hour ":" time-minute ":" time-second
[time-secfrac] time-zone
date-time = full-date "T" full-time
5.5 Examples
Here are two examples of this date and time format.
1985-04-12T23:20:50,5Z
This represents 20 minutes and 50.5 seconds after 11 PM on April
12th, 1985 in UTC.
1996-12-19T16:39:57-08:00
This represents 39 minutes and 57 seconds after 4 PM on December
19th, 1996 with an offset of -08:00 from UTC (Pacific Standard
Time).
6. IANA Registry of Timezone Names
[XXX - put good stuff here]
7. References
[ISO8601] "Data elements and interchange formats -- Information
interchange -- Representation of dates and times", ISO 8601:1988(E),
International Organization for Standardization, June, 1988.
Newman [Page 5]
Internet Draft Date and Time December 1996
[IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text
Messages", RFC 822, University of Delaware, August 1982.
<ftp://ds.internic.net/rfc/rfc822.txt>
[HOST-REQ] Braden, R., "Requirements for Internet Hosts -- Application
and Support", RFC 1123, Internet Engineering Task Force, October 1989.
<ftp://ds.internic.net/rfc/rfc1123.txt>
[NTP] Mills, D., "Network Time Protocol version 2 specification and
implementation", RFC 1119, September 1989.
<ftp://ds.internic.net/rfc/rfc1119.ps>
8. Security Considerations
Since the local time zone of a site may be useful for determining a
time when systems are less likely to be monitored and might be more
susceptible to a security probe, some sites may wish to emit times
in UTC only. Others might consider this to be loss of useful
functionality at the hands of paranoia.
9. Author's Address
Chris Newman
Innosoft International, Inc.
1050 East Garvey Ave. South
West Covina, CA 91790 USA
Email: chris.newman@innosoft.com
APPENDIX
A. ISO 8601 Collected ABNF
ISO 8601 does not specify a formal grammar for the date and time
formats it defines. The following is an attempt to create a formal
grammar from ISO 8601. This is informational only and may contain
errors. ISO 8601 remains the authoratative reference for the
complete syntax.
date-century = 2DIGIT ; 00-99
date-decade = DIGIT ; 0-9
date-subdecade = DIGIT ; 0-9
date-year = date-decade date-subdecade
Newman [Page 6]
Internet Draft Date and Time December 1996
date-fullyear = date-century date-year
date-month = 2DIGIT ; 01-12
date-wday = DIGIT ; 1-7 ; 1 is Monday, 7 is Sunday
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on month/year
date-yday = 3DIGIT ; 001-365, 001-366 based on year
date-week = 2DIGIT ; 01-52, 01-53 based on year
datepart-fullyear = [date-century] date-year ["-"]
datepart-ptyear = "-" [date-subdecade ["-"]]
datepart-wkyear = datepart-ptyear / datepart-fullyear
dateopt-century = "-" / date-century
dateopt-fullyear = "-" / datepart-fullyear
dateopt-year = "-" / (date-year ["-"])
dateopt-month = "-" / (date-month ["-"])
dateopt-week = "-" / (date-week ["-"])
datespec-full = datepart-fullyear date-month ["-"] date-mday
datespec-year = date-century / dateopt-century date-year
datespec-month = "-" dateopt-year date-month [["-"] date-mday]
datespec-mday = "--" dateopt-month date-mday
datespec-week = datepart-wkyear "W" (date-week / dateopt-week date-wday)
datespec-wday = "---" date-wday
datespec-yday = dateopt-fullyear date-yday
date = datespec-full / datespec-year / datespec-month /
datespec-mday / datespec-week / datespec-wday / datespec-yday
Time:
time-hour = 2DIGIT ; 00-24
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-60
time-fraction = ("," / ".") 1*DIGIT
time-numzone = ("+" / "-") time-hour [[":"] time-minute]
time-zone = "Z" / time-numzone
timeopt-hour = "-" / (time-hour [":"])
timeopt-minute = "-" / (time-minute [":"])
timespec-hour = time-hour [[":"] time-minute [[":"] time-second]]
timespec-minute = timeopt-hour time-minute [[":"] time-second]
timespec-second = "-" timeopt-minute time-second
timespec-base = timespec-hour / timespec-minute / timespec-second
time = timespec-base [time-fraction] [time-zone]
iso-date-time = date "T" time
Newman [Page 7]
Internet Draft Date and Time December 1996
Durations (periods):
dur-second = 1*DIGIT "S" dur-minute = 1*DIGIT "M"
[dur-second] dur-hour = 1*DIGIT "H" [dur-minute] dur-time
= "T" (dur-hour / dur-minute / dur-second) dur-day =
1*DIGIT "D" dur-week = 1*DIGIT "W" dur-month =
1*DIGIT "M" [dur-day] dur-year = 1*DIGIT "Y" [dur-month]
dur-date = (dur-day / dur-month / dur-year) [dur-time]
duration = "P" (dur-date / dur-time / dur-week)
Periods:
period-explicit = date-time "/" date-time period-start =
date-time "/" duration period-end = duration "/" date-time
period = period-explicit / period-start / period-end
B. Zeller's Congruence [XXX-ref]
The following is sample C code which may be used to obtain the day
of the week:
char *dayofweek[] = {
"Sunday", "Monday", "Tuesday", "Wednesday",
"Thursday", "Friday", "Saturday"
};
void main()
{
int cent, year, day, month;
printf("Enter the year (4 digits): ");
scanf("%d", &year);
printf("\nEnter the month (1-12): ");
scanf("%d", &month);
printf("\nEnter the day of the month (1-31): ");
scanf("%d", &day);
month -= 2;
if (month < 1) {
month += 12;
year--;
}
cent = year / 100;
year %= 100;
printf("The day of the week is: %s\n",
dayofweek[((26 * month - 2) / 10 + day + year
Newman [Page 8]
Internet Draft Date and Time December 1996
+ year / 4 + cent / 4 - 2 * cent) % 7]);
}
Newman [Page 9]