refactor(date)!: fail on invalid dates

[ST-DDT]

If a given date is invalid, it is treated as an error instead of falling back to refDateSource

[netlify]

✅ Deploy Preview for fakerjs ready!

Name	Link
🔨 Latest commit	dca3569
🔍 Latest deploy log	https://app.netlify.com/sites/fakerjs/deploys/660020fd0300ae00082f30aa
😎 Deploy Preview	https://deploy-preview-2757.fakerjs.dev
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.94%. Comparing base (45150d1) to head (dca3569).

Additional details and impacted files

@@            Coverage Diff             @@
##             next    #2757      +/-   ##
==========================================
+ Coverage   99.92%   99.94%   +0.01%     
==========================================
  Files        2958     2958              
  Lines      213713   213686      -27     
  Branches      947      949       +2     
==========================================
+ Hits       213560   213569       +9     
+ Misses        153      117      -36     

Files	Coverage Δ
src/modules/date/index.ts	100.00% <100.00%> (+0.17%)	⬆️

... and 2 files with indirect coverage changes

[Shinigami92]

I wondered why the snapshots are different, but this is due to not calling date.setTime(future/past) anymore. This is okay to me, as it is still on the same Day, but just a different time.

So there is only one thing we can improve in the vitest test, and then I'm okay with approving this

[ST-DDT]

I wondered why the snapshots are different, but this is due to not calling date.setTime(future/past) anymore. This is okay to me, as it is still on the same Day, but just a different time.

Both date and time are different for all methods in the past. Because we now generate the range directly instead of subtracting it. So the result is basically flipped.