]> Henlich Engineering

Gruenewaldstr. 57 Heilbronn 74080 DE thomas@henlich.de https://henlich.de/

General Internet Engineering Task Force date format calendar human-readable This document defines the Internet Month-Name Date Format (IMDF), a concise date representation for English-language human communication. IMDF requires an alphabetic month abbreviation. This makes the month visually distinct from the numeric day and reduces errors caused by differing regional date-order conventions. The specification primarily defines how IMDF dates are presented. It establishes a preferred output form and permits a limited set of familiar English-language variants. Detailed input handling is outside its scope. IMDF does not replace ISO 8601 for machine interchange, language- neutral communication, chronological sorting, or timestamps.

Introduction

Purpose All-numeric date formats can be misinterpreted when readers use different regional conventions. For example:

• 01/02/2026
• 02/01/2026
• 01.02.2026
• 02-01-26

Such forms do not visually identify which numeric field is the day and which is the month. A reader may automatically apply a familiar ordering and fail to notice that the writer intended another one. Several established protocol specifications demonstrate the long-standing Internet practice of using alphabetic month abbreviations to eliminate date ambiguity. These include ARPA Internet text messages (RFC 822 ), Internet Message Format (RFC 5322 ), and HTTP Semantics (RFC 9110 ). However, those formats include protocol-heavy elements (timestamps, mandatory seconds, or time-zone offsets) optimized for machine parsing rather than concise human communication. IMDF addresses this problem by extracting that proven principle, using an English alphabetic month abbreviation, and applying it to a streamlined, presentation-only format for human-facing text:

• 05 Jan 2026
• Jan 05
• Mon, 05 Jan 2026

In each example, the alphabetic component unmistakably identifies the month. The primary objective of IMDF is to reduce human interpretation errors in English-language date communication.

Design Principles IMDF is guided by the following principles.

1. A month should never be mistaken for a day.
   Every IMDF date contains an alphabetic month abbreviation. The month is therefore visually distinct from the numeric day.
2. Favor brevity.
   IMDF uses three-letter month and weekday abbreviations so that dates remain practical in messages, comments, tickets, reports, presentations, and calendar annotations.
3. Avoid number following number.
   Alternating numeric and alphabetic components makes the date structure easier to recognize. IMDF favors 05 Jan 2026 rather than an all-numeric sequence such as 05 01 2026.
4. Respect established English-language conventions.
   IMDF permits limited day-month and month-day variation when no year is shown. This accommodates familiar English-language usage without making the month ambiguous.
5. Prefer a unique canonical representation.
   IMDF defines one preferred output form for consistent presentation.

Scope IMDF represents a calendar date for human-readable English-language output. An IMDF date MAY include a year or MAY omit it. When omitted, the year may be understood from context, supplied by surrounding text or metadata, intentionally irrelevant, or omitted because the date is recurring. IMDF does not define how an omitted year is interpreted. IMDF does not represent an instant, time of day, duration, or time zone. ISO 8601 SHOULD be used when language neutrality, machine interchange, chronological sorting, or non-English interoperability is required.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. A "producer" is a person or implementation that presents an IMDF date. "Canonical form" means the preferred output representation defined in .

Preferred Output

Canonical Form Producers SHOULD present IMDF dates in this canonical form: where:

• ddd is an optional weekday abbreviation;
• DD is a two-digit day of the month;
• MMM is a three-letter month abbreviation; and
• YYYY is an optional four-digit year.

Canonical examples:

• Mon, 05 Jan 2026
• 05 Jan 2026
• Mon, 05 Jan
• 05 Jan

Month The month MUST be represented by one of these English abbreviations: The first letter SHOULD be uppercase and the remaining letters lowercase.

Day In canonical output, the day MUST contain two decimal digits. A leading zero MUST be used for days 1 through 9. Examples:

• 01 Jan
• 05 Jan
• 24 Aug

Year When present, the year MUST contain four decimal digits and MUST follow the month. Examples:

• 05 Jan 2026
• Mon, 24 Aug 2026

Month-day-year output is not IMDF:

• Jan 05 2026

Weekday A weekday MAY be included using one of these English abbreviations: In canonical output, the weekday MUST precede the day and MUST be followed by a comma and one space. Examples:

• Mon, 05 Jan 2026
• Mon, 05 Jan

The weekday SHOULD correspond to the represented calendar date when the year is known.

Syntax (ABNF) The syntax of IMDF dates is specified using Augmented Backus-Naur Form (ABNF) as defined in .

Permitted Yearless Variants

General A limited set of noncanonical variants MAY be used when the year is absent. These variants reflect common English-language usage while retaining an alphabetic month. Producers SHOULD use the canonical form unless a permitted variant is more natural in the surrounding text.

Day-Month Variant Without Weekday Comma In a yearless day-month date, the comma after a weekday MAY be omitted:

• Mon 05 Jan

The canonical equivalent is:

• Mon, 05 Jan

Month-Day Variant When the year is absent, the month MAY precede the day:

• Jan 05

If a weekday is included with month-day order, the weekday MUST be followed by a comma:

• Mon, Jan 05

The following form is not IMDF:

• Mon Jan 05

Single-Digit Day in Informal Output Informal output MAY omit the leading zero:

• 5 Jan
• Jan 5
• Mon 5 Jan
• Mon, Jan 5

Producers SHOULD use the two-digit day in canonical output.

Output Summary Canonical output: Additional permitted yearless output: The following rules summarize IMDF output:

1. The month is always alphabetic.
2. A displayed year always follows the month.
3. Canonical output always places the day before the month.
4. Canonical output always uses a two-digit day.
5. Canonical output uses a comma after a displayed weekday.
6. Month-day order is permitted only when the year is absent.
7. A weekday before a month-day date always requires a comma.

Applicability

Recommended Uses IMDF is intended for English-language human-facing content such as:

• messages and correspondence;
• comments and issue tickets;
• technical documentation and reports;
• presentations;
• calendar annotations; and
• short textual labels.

Uses Requiring Another Format ISO 8601 SHOULD be preferred for:

• multilingual or language-neutral communication;
• machine interchange and software interfaces;
• database storage;
• chronological filename sorting; and
• applications requiring a standardized numeric date.

A date-time format containing an offset or other time-zone information MUST be used when an absolute instant is required.

Internationalization Considerations IMDF uses English ASCII weekday and month abbreviations. Localized names are not IMDF. IMDF SHOULD be used only where English-language date notation is expected and understood. A localized format or ISO 8601 SHOULD be used in other language contexts.

Security Considerations Ambiguous date interpretation can cause incorrect scheduling, retention, validity, or processing decisions. IMDF reduces this risk by making the month alphabetic and visually distinct from the numeric day. A yearless IMDF date does not identify a unique calendar year. A specific year MUST NOT be assumed unless it is provided by context outside IMDF. IMDF contains neither a time of day nor a time zone. It MUST NOT be used to represent an absolute instant.

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] This document revises the specifications in RFC 733, in order to serve the needs of the larger and more complex ARPA Internet. Some of RFC 733's features failed to gain adequate acceptance. In order to simplify the standard and the software that follows it, these features have been removed. A different addressing scheme is used, to handle the case of internetwork mail; and the concept of re-transmission has been introduced. Obsoletes RFC 733, NIC 41952. This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK] The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. International Organization for Standardization

Examples

Canonical IMDF

• Mon, 05 Jan 2026
• 05 Jan 2026
• Mon, 05 Jan
• 05 Jan

Permitted Yearless Variants

• Mon 05 Jan
• Jan 05
• Mon, Jan 05
• 5 Jan
• Jan 5
• Mon 5 Jan
• Mon, Jan 5

Not IMDF

• 24 August 2026 - Full month names are not defined.
• 24-AUG-2026 - Hyphens are not defined.
• 2026 Aug 24 - Year-first order is not defined.
• Jan 05 2026 - Month-day order cannot include a year.
• Mon 24 Aug 2026 - A weekday before a dated year needs comma.
• Mon Jan 05 - Month-day order requires a weekday comma.
• 24/08/2026 - The month is numeric.
• 2026-08-24 - This is ISO 8601, not IMDF.

Revision History