Use only FoundationEssentials when possible

[t089]

Linking against Foundation on linux adds a hefty binary size penalty. Mostly due to the ICU data from FoundationInternationalization. To address this we conditionally import FoundationEssentials instead of Foundation if possible and replace Foundation-only API with a different implementation.

Motivation:

Smaller binary sizes are better.

Modifications:

• Replace import Foundation with import FoundationEssentials.
• Update date parsing logic to use newer API if available.
• Implement a custom parser for RFC5322 dates

Result:

Ability to build the package without linking Foundation.

[sebsto]

LGTM

[sebsto]

Thank you @t089 !
There is an issue with the license headers on some files and a couple of formatting checks that fails to validate
See https://github.com/swift-server/swift-aws-lambda-events/actions/runs/12408957260 for the details

To check the formatting, I usually download the script from https://github.com/swiftlang/github-workflows/blob/main/.github/workflows/scripts/check-swift-format.sh and run it locally.

[t089]

Hm I don't think this will actually compile on older swift versions on Linux where this api is not yet available in Foundation, need to check.

[t089]

Yeah there are a bunch of build errors with swift 5.10 on linux. will look into it.

[sebsto]

The next version will support Swift 6 and onwards, aligned on the Swift Lambda Runtime

[sebsto]

Let me know if you want to fix this or not. I'm happy to merge with a Swift 6 only change. If there is an easy fix, let's be nice with our existing users.

[t089]

Actually the if #available(macOS 12, *) check was redundant as the conditional compile already excludes macOS altogether. Now it should compile for both on linux and macOS.

[sebsto]

@t089 looks like your last commit breaks the Swift 6 unit tests
https://github.com/swift-server/swift-aws-lambda-events/actions/runs/12413722400/job/34657011160?pr=81

[t089]

@sebsto should be good now! got a bit confused with all the platform specific checks...

[sebsto]

Merged - thank you !

[adam-fowler]

Given this is being used with more than HTTP headers I think we need to extend the number of timezone identifiers. The list is missing standard ones listed in RFC PST, EST, MST, CST (funnily RFC only lists US zones). Also does the parser deal with additional characters at the en. It is common to see email dates written as follows Sun, 22 Sep 2024 18:46:31 +0100 (BST) with the three character timezone at the end.

[sebsto]

@adam-fowler these are valid concerns indeed. I created #85 to follow up

[t089]

Given this is being used with more than HTTP headers I think we need to extend the number of timezone identifiers. The list is missing standard ones listed in RFC PST, EST, MST, CST (funnily RFC only lists US zones).

This is fair, I was assuming this is only used with AWS APIs where UTC/GMT should suffice.

Also does the parser deal with additional characters at the en. It is common to see email dates written as follows Sun, 22 Sep 2024 18:46:31 +0100 (BST) with the three character timezone at the end.

Yes I think this should be covered:

    func testWithLeadingDayName() throws {
        let input = "Fri, 26 Jun 2020 03:04:03 -0500 (CDT)"
        let date = try strategy.parse(input)
        XCTAssertEqual("2020-06-26 08:04:03 +0000", date.description)
    }

The Tz in brackets is ignored.

[adam-fowler]

This is fair, I was assuming this is only used with AWS APIs where UTC/GMT should suffice

For SES you are decoding the email header which could come from any email provider.