Fix: Use uninitialized memory while parsing Date header

[tyler92]

Fixes #1316

I update the hinnant-date subproject up to version v3.0.3 without changes in the copyrights section. The main fix for #1316 is long double S{}; instead of long double S;. Probably it's worth to make this project as a submodule, but I think it's out of the scope for this PR.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 76.04%. Comparing base (26f4494) to head (059a8ec).
Report is 2 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1317      +/-   ##
==========================================
- Coverage   76.12%   76.04%   -0.09%     
==========================================
  Files          61       61              
  Lines        9013     8916      -97     
==========================================
- Hits         6861     6780      -81     
+ Misses       2152     2136      -16     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Tachi107]

Yeah, I agree this should be either a subproject or a meson wrap, to make updating to new versions easier. Generally expect users to use the system version of howardhinnant-date, though, so these kind of bugs go unnoticed.

Edit: the reason this isn't a meson wrap already is because it was used to build the pistache package in the Ubuntu PPA, but now that libhowardhinnant-date-dev exists we can make it a regular wrap.

[kiplingw]

@tyler92, I think it's a useful PR. But like @Tachi107 said, we think it might be in the wrong place. I'd encourage you to submit it upstream.

[tyler92]

@kiplingw The fix is already in that repo: HowardHinnant/date#698

I didn't make any manual changes, only updated code from that repository

[kiplingw]

Yes, looks like it's merged already upstream. We could either create an updated package for the library in our Pistache Build Dependencies PPA until we have an updated system package available, or we could just wait for upstream to sync with Debian and its derivatives (looks like @Tachi107 may have already taken care of this). The former is an immediate solution, but needs some work to create the package. The latter is not immediate, but a long term solution with less work on our end.

[tyler92]

OK, thanks for your answers! I'm not very experienced with creating packages, so I’ll leave that part - and the decision about Debian - to whoever feels comfortable taking it on.

As for this PR, feel free to close or merge it, depending on what you decide

[Tachi107]

On Sun May 18, 2025 at 7:11 PM CEST, Kip wrote: But like @Tachi107 said, we think it might be in the wrong place. I'd encourage you to submit it [upstream](https://github.com/HowardHinnant/date).

To be clear, this is not exactly what I said. I'm fine with this PR, as it just updates our bundled date library to the latest upstream version. What I was suggesting is to unbundle the header and use a meson wrap file instead. But this is a suggestion for the future. Merging :)