runtime: System.Net.Http.Headers.DateHeaderParser in FW 4.7.2 doesn't support numerous date/time formats (UTC specifically)

Threw together the below monkey patch for this issue in about 15 minutes - which is still more time than Microsoft took to test how well HttpClient parses headers. It’s ugly, it’s dirty, but it works and it solves the issue and best of all: it doesn’t require Microsoft to do anything more than the nothing they were already doing. It also works on both Framework and Core, since this fix is only in Core 3.x.

using System;
using System.Net.Http;
using System.Reflection;
using System.Runtime.Versioning;

namespace MonkeyPatch
{
    public static class HttpClientDateHeaderParser
    {
        // taken from https://github.com/dotnet/corefx/blob/master/src/Common/src/System/Net/HttpDateParser.cs#L11
        private static readonly string[] s_dateFormats = new string[] {
            // "r", // RFC 1123, required output format but too strict for input
            "ddd, d MMM yyyy H:m:s 'GMT'", // RFC 1123 (r, except it allows both 1 and 01 for date and time)
            "ddd, d MMM yyyy H:m:s 'UTC'", // RFC 1123, UTC
            "ddd, d MMM yyyy H:m:s", // RFC 1123, no zone - assume GMT
            "d MMM yyyy H:m:s 'GMT'", // RFC 1123, no day-of-week
            "d MMM yyyy H:m:s 'UTC'", // RFC 1123, UTC, no day-of-week
            "d MMM yyyy H:m:s", // RFC 1123, no day-of-week, no zone
            "ddd, d MMM yy H:m:s 'GMT'", // RFC 1123, short year
            "ddd, d MMM yy H:m:s 'UTC'", // RFC 1123, UTC, short year
            "ddd, d MMM yy H:m:s", // RFC 1123, short year, no zone
            "d MMM yy H:m:s 'GMT'", // RFC 1123, no day-of-week, short year
            "d MMM yy H:m:s 'UTC'", // RFC 1123, UTC, no day-of-week, short year
            "d MMM yy H:m:s", // RFC 1123, no day-of-week, short year, no zone

            "dddd, d'-'MMM'-'yy H:m:s 'GMT'", // RFC 850
            "dddd, d'-'MMM'-'yy H:m:s 'UTC'", // RFC 850, UTC
            "dddd, d'-'MMM'-'yy H:m:s zzz", // RFC 850, offset
            "dddd, d'-'MMM'-'yy H:m:s", // RFC 850 no zone
            "ddd MMM d H:m:s yyyy", // ANSI C's asctime() format

            "ddd, d MMM yyyy H:m:s zzz", // RFC 5322
            "ddd, d MMM yyyy H:m:s", // RFC 5322 no zone
            "d MMM yyyy H:m:s zzz", // RFC 5322 no day-of-week
            "d MMM yyyy H:m:s", // RFC 5322 no day-of-week, no zone
        };

        public static bool DoMicrosoftsJob()
        {
            var framework = Assembly
                .GetEntryAssembly()?
                .GetCustomAttribute<TargetFrameworkAttribute>()?
                .FrameworkName;

            string dateFormatsFieldName;
            if (string.IsNullOrWhiteSpace(framework) || framework.IndexOf("framework", StringComparison.InvariantCultureIgnoreCase) != -1) dateFormatsFieldName = "dateFormats";
            else dateFormatsFieldName = "s_dateFormats";

            var httpClientType = typeof(HttpClient);
            var systemNetHttpAssembly = httpClientType.Assembly;

            var httpRuleParserType = systemNetHttpAssembly.GetType("System.Net.Http.HttpRuleParser");
            if (httpRuleParserType == null) return false;

            var dateFormatsField = httpRuleParserType.GetField(dateFormatsFieldName, BindingFlags.NonPublic | BindingFlags.Static);
            if (dateFormatsField == null) return false;

            dateFormatsField.SetValue(null, s_dateFormats);
            return true;
        }
    }
}

@IanKemp

For reference, the change that added the extra date/time formats was made in dotnet/corefx#28843 - about a year ago. This comment indicates that the change probably should be considered for backporting to the Framework - not sure if that got lost and forgotten along the way, or was decided against, or…

The change was not ported back to .NET Framework. There are no plans to do so. .NET Framework is much more sensitive to changes which could cause applications to break since it is installed on the machine and used globally by all .NET Framework applications.