[API Proposal]: Add 'e' format specifier for "extended date" in DateTime formatting

[crwsolutions]

Background and motivation

In many scenarios, developers need a culture-specific date format that represents a "long date" without the day of the week (e.g., "October 31, 1999" for en-US, instead of the full "D" format like "Sunday, October 31, 1999"). Currently, this requires custom formatting strings, which can be repetitive. Adding a standard 'e' specifier would provide a convenient, built-in option.

In my situation (dutch) I want to display a date of birth, adding a weekday is awkward in this context.

API Proposal

Introduce a new standard format specifier 'e' for "extended date," which is culture-specific and based on a new property DateTimeFormatInfo.ExtendedDatePattern. This would fit naturally into the existing table of pre-defined format characters:

        Format              Description                             Real format                             Example
        =========           =================================       ======================                  =======================
        "d"                 short date                              culture-specific                        10/31/1999
        "D"                 long data                               culture-specific                        Sunday, October 31, 1999
        "e"                 extended date                           culture-specific                        October 31, 1999
        "f"                 full date (long date + short time)      culture-specific                        Sunday, October 31, 1999 2:00 AM
        "F"                 full date (long date + long time)       culture-specific                        Sunday, October 31, 1999 2:00:00 AM
        "g"                 general date (short date + short time)  culture-specific                        10/31/1999 2:00 AM
        "G"                 general date (short date + long time)   culture-specific                        10/31/1999 2:00:00 AM
        "m"/"M"             Month/Day date                          culture-specific                        October 31
(G)     "o"/"O"             Round Trip XML                          "yyyy-MM-ddTHH:mm:ss.fffffffK"          1999-10-31 02:00:00.0000000Z
(G)     "r"/"R"             RFC 1123 date,                          "ddd, dd MMM yyyy HH':'mm':'ss 'GMT'"   Sun, 31 Oct 1999 10:00:00 GMT
(G)     "s"                 Sortable format, based on ISO 8601.     "yyyy-MM-dd'T'HH:mm:ss"                 1999-10-31T02:00:00
                                                                    ('T' for local time)
        "t"                 short time                              culture-specific                        2:00 AM
        "T"                 long time                               culture-specific                        2:00:00 AM
(G)     "u"                 Universal time with sortable format,    "yyyy'-'MM'-'dd HH':'mm':'ss'Z'"        1999-10-31 10:00:00Z
                            based on ISO 8601.
(U)     "U"                 Universal time with full                culture-specific                        Sunday, October 31, 1999 10:00:00 AM
                            (long date + long time) format
                            "y"/"Y"             Year/Month day                          culture-specific                        October, 1999

This would update AllStandardFormats to include 'e' and handle it in ExpandStandardFormatToCustomPattern by returning the culture-specific dtfi.ExtendedDatePattern.

API Usage

DateTime date = new DateTime(1999, 10, 31, 14, 0, 0);

        // Using the new 'e' format specifier for extended date
        string enUsExtended = date.ToString("e", CultureInfo.CreateSpecificCulture("en-US"));
        string frFrExtended = date.ToString("e", CultureInfo.CreateSpecificCulture("fr-FR"));

        Console.WriteLine(enUsExtended); // Output: October 31, 1999
        Console.WriteLine(frFrExtended); // Output: 31 octobre 1999

Alternative Designs

Using custom formats like "MMMM d, yyyy" works, but a standard specifier would improve consistency and discoverability, especially for globalization-aware apps.

Solutions presented on StackOverflow are somewhat tricky, and shows developers are struggling with this.

Risks

Adding 'e' is extremely low-risk:

• 'e' is not currently a standard format specifier, so there’s no breaking change.
• Existing code using ToString with other format specifiers is unaffected.
• It’s fully optional; developers who don’t use it see no difference.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-datetime
See info in area-owners.md if you want to be subscribed.