Formatting and parsing support for RFC 7231 HTTP-dates

[lionel-rowe]

Add formatting and parsing support for RFC 7231 HTTP-dates, as used in HTTP headers (Expires, Last-Modified, etc) and cookies.

Advantages:

There's clear utility, as it's a ubiquitous format on the web, due to being used in many common HTTP headers and cookies. Currently the best way of handling in JS is to use the Date methods, but that's not ideal as Date is already being referred to as "legacy" in the Temporal documentation due to its many drawbacks. One could reasonably expect "no Date" to become a common linter rule once Temporal achieves widespread platform support.

Date also doesn't implement validation for the string parsing — arbitrary strings will never throw and may or may not return valid dates that may or may not be what was expected.

In addition, Date parsing fails to fully implement HTTP-date as specified in RFC 7231, as the two obsolete (pre-1995) formats aren't accounted for.

Concerns:

None that I can think of

Prior art:

Formatting:

• Date.prototype.toUTCString

Parsing:

• Date.parse, or by extension the Date constructor, which uses the same parsing logic
  • Implementations should correctly handle the string values generated by toUTCString
  • The two obsolete (pre-1995) formats mentioned by RFC 7231 are unspecified

Constraints / corner cases:

• How strict should parsing be — for example, should Mon, 06 Nov 1994 08:49:37 GMT throw due to that date being a Sunday not a Monday?
• Should the two obsolete (pre-1995) formats mentioned by RFC 7231 be included in the parsing logic? I have no idea how common these are in-the-wild as of 2023.
• Names/locations of the new methods — maybe something like Temporal.Instant.toHttpDateString and Temporal.Instant.fromHttpDateString? Logically, Instant seems to make more sense than ZonedDateTime, despite the IMF-fixdate and rfc850-date formats specifying "GMT" (it's always GMT).

[ryzokuken]

I would say that parsing this format was one of the bigger drawbacks of Date and there's strong reasons for implementers and other folks to be skeptical of the format. The current plan is to stick to the ISO 8601-like formats for interchange and serialization in JavaScript and all other formats (both parsing and formatting) could be done using light userland helper libraries.

[lionel-rowe]

The current plan is to stick to the ISO 8601-like formats for interchange and serialization in JavaScript

ISO 8601 is definitely "better" for interchange for various reasons, but it's not the format used by various standard HTTP headers or cookies, whether those originate in JS or any other language. Given the wide usage of this format by core web technologies, it seems this would be a useful thing to have a standard web/browser API for, even if it wasn't collocated with Temporal. Arguably it's more of a standard library concern, but of course JS doesn't have a standard library.

[ryzokuken]

I completely agree with you that while ISO 8601 (and friends) is generally more suitable for interchange, other formats are prevalent across the web such as this one. One thing it has in its favor is that it will continue to be supported via Date forever and while you raised concerns about lint rules disallowing the use of Date, I believe that since it can still be overruled, it's not as big of a problem, atleast not compared to JavaScript exposing this functionality from two different API surfaces.

[lionel-rowe]

Sure, makes sense. I'll leave the issue open for now, but feel free to close if this is definitely considered out of scope.

[ryzokuken]

Let's leave it open for others to comment. Perhaps I'm in the minority here and others are more open to the idea.

[TheOneTheOnlyJJ]

Given how common HTTP-dates are, I would suggest supporting this out-of-the-box with Temporal. Not doing it would make a sizeable proportion of the web rely on 3rd party libraries, which could be avoided in this case. Common operations on standardised formats such as this one should not require additional dependencies.

[lionel-rowe]

Not doing it would make a sizeable proportion of the web rely on 3rd party libraries

@TheOneTheOnlyJJ To clarify, this is already supported by Date.prototype.toUTCString and Date.parse, so there's no need for third-party libraries. The reason I'm suggesting adding it to Temporal is that Temporal can largely replace Date once it achieves widespread support; having certain essential functionality that's only available via Date complicates that story somewhat. But in any case, Date will still be around forever to avoid breaking the web, so there won't be any need for third-party libraries (except for cases like stricter RFC 7231 compliance/support for obsolete formats).

[TheOneTheOnlyJJ]

After giving this some more thought, I think I've found an optimal solution.

Maybe we could expose this functionality through a predefined string we pass to the format/strftime function suggested in #5. To me, this makes the most sense, as it would remove any specific custom logic for this specific format. The need for using the to-be-deprecated Date will be removed.

There's great support in the community for #5 to be adopted, and by approaching the issue in this way we cement support for it even further. Even if not looking at it through the lens of a #5 supporter, this still is the best logical approach to use. No string format should have its own custom logic in the library. All formats should leverage a common formatting core ability of the library for the best extensibility.

There could also be other predefined format strings besides this one, for popular & widely-adopted formats. As they would all be just constant format strings, we could expose as many of them as we see fit. Users could freely define their own as well, but the most common formats should be provided out-of-the-box to avoid any potential common errors and improve DX.

I'm looking forward for your feedback on this approach.