[Review] SF-0016: HTTP Date Format

Hello Swift community,

The review of HTTP Date Format begins now and runs through Feb 11, 2025.

Reviews are an important part of the Swift-Foundation evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager by email or DM. When contacting the review manager directly, please include proposal name in the subject line.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift-Foundation. When writing your review, here are some questions you might want to
answer in your review:

  • What is your evaluation of the proposal?
  • Does this proposal fit well with the feel and direction of Swift-Foundation?
  • If you have used other languages or libraries with a similar
    feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick
    reading, or an in-depth study?

More information about Swift-Foundation review process is available at

swift-foundation/CONTRIBUTING.md at main · swiftlang/swift-foundation · GitHub

Thank you,

Tina L
Review Manager

5 Likes

Big +1 from me. Many server instances want to be able to remove dependencies on big Foundation and only import essentials. Additionally it's a well known, defined standard format that will be useful for the wider ecosystem.

Specific nits:

Foundation does not support leap seconds, so values of 60 for the seconds field are set to 0 instead.

It seems incongruous that "January 99, 2025" parses correctly but not an actual calendrical leap second. What is it about the underlying implementation that permits representation of the 99th day of the month but not the 60th second of the minute?

Separately, even if it were decided consistently that clearly out-of-range date components are not representable, it seems that the resulting operation to bring it in-range should be saturating rather than resetting to zero. That is to say, 23:59:60 should become 23:59:59 rather than 23:59:00.

For fields like the weekday, day number and year number, the style will make a best effort at parsing a sensible date out of the values in the string.

Not objecting to best effort, but particularly for a parser that's ingesting a format specified by a standard, I think this is underspecified. Can there be more given here as to how the best effort process will operate on ill-formed inputs?

7 Likes

I think having first class parsing and formatting additions for DateComponents are going to be very useful beyond the HTTP Date Format use case.

+1. Sounds like a good and worthwhile addition / unification, considering that there are many 3rdparty implementations of this.

+1 from me.

This gets us one step closer to building server components that don't require the much larger Foundation.