Handle the DateTimeImmutable class.

[sukei]

Add the support of DateTimeImmutable class in the DateTimeExtension. Both as a valid argument for formatTimestamp, dateTime, and timestamp existing methods, plus an additional dateTimeImmutable. This is a must have feature for projects that prefer DateTimeImmutable over DateTime and it fix a known issue of the old FakerPHP implementation.

Summary by CodeRabbit

• New Features

  • Added support for generating immutable date-time values alongside the existing mutable date-time output.
  • Expanded date-time handling to accept a wider range of time input types.

• Bug Fixes

  • Improved timestamp processing so date-time-related values are handled more consistently across supported inputs.

• Tests

  • Updated coverage to verify immutable date-time results and confirm generated timestamps stay within the expected range.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 477bd926-3614-4f3a-bcb8-d1edafd514da

📥 Commits

Reviewing files that changed from the base of the PR and between 772724b and af7335c.

📒 Files selected for processing (2)

• src/Extensions/DateTimeExtension.php
• tests/Unit/Extensions/DatetimeExtensionTest.php

---

📝 Walkthrough

Walkthrough

DateTimeExtension's type hints are widened from DateTime to DateTimeInterface across formatTimestamp, dateTime(), and timestamp() methods. A new dateTimeImmutable() public method is added returning DateTimeImmutable. Tests are extended to validate the new method's return type and timestamp bounds.

Changes

DateTimeInterface widening and immutable support

Layer / File(s)	Summary
Widen type hints and add dateTimeImmutable method src/Extensions/DateTimeExtension.php	Imports and formatTimestamp are updated to accept DateTimeInterface, dateTime() and timestamp() parameter types are widened, and a new dateTimeImmutable() method is added returning DateTimeImmutable.
Test coverage for dateTimeImmutable tests/Unit/Extensions/DatetimeExtensionTest.php	Test suite imports DateTimeImmutable and extends testDateTimeImmutable() to assert instance type and timestamp bounds.

Estimated code review effort: 2 (Simple) | ~10 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title is concise and clearly points to the new DateTimeImmutable support added in this change.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[nikophil]

💯 for this, it is needed for a longtime in the original FakerPHP lib.

But I really think a DateTimeExtension should rely on an implementation of psr/clock, WDYT?

[sukei]

But I really think a DateTimeExtension should rely on an implementation of psr/clock

I opened another PR that would give us the opportunity to use a fixed seed and get reproducible results. However, some extensions are not fully ready for that yet, and DateTimeExtension is one of them.

Thanks to the seed, the calculated time offsets become reproducible, but the extension still relies on 'now' when applying those offsets. As a result, the generated values still drift over time.

Using psr/clock would, among other things, allow us to freeze 'now' and move further toward fully reproducible results. That said, I think we'd need some form of DI container to be able to inject this kind of dependency.

[nikophil]

Thanks to the seed, the calculated time offsets become reproducible, but the extension still relies on 'now' when applying those offsets. As a result, the generated values still drift over time.

Using psr/clock would, among other things, allow us to freeze 'now' and move further toward fully reproducible results. That said, I think we'd need some form of DI container to be able to inject this kind of dependency.

💯 OK with this