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. [HOST-REQ] Braden, R., "Requirements for Internet Hosts -- Application and Support", RFC 1123, Internet Engineering Task Force, October 1989. [NTP] Mills, D., "Network Time Protocol version 2 specification and implementation", RFC 1119, September 1989. 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]