A DateTime filter

[gszy]

This is a new filter that returns DateTime or (if desired) DateTimeImmutable instances.

[froschdesign]

@gscscnd
Thank you for the pull request and contribution, but did you see the filter DateTimeFormatter?

https://github.com/zendframework/zend-filter/blob/master/src/DateTimeFormatter.php

[gszy]

@froschdesign, it seems that DateTimeFormatter returns a string, while I would like to receive DateTimeInterface.

[froschdesign]

@gscscnd
You are right. (Never read on phone in the sun! 🤦‍♂️ )

---

The following filtering is support:

• string to DateTime
• string to DateTimeImmutable
• DateTime to DateTimeImmutable
• DateTimeImmutable to DateTime

Is this correct or did I forget something?

[gszy]

• string to DateTime
• string to DateTimeImmutable

Actually I don’t check if a string was provided, just pass it to DateTime/DateTimeImmutable constructor.

• DateTime to DateTimeImmutable
• DateTimeImmutable to DateTime

Also DateTime to DateTime and similarly for immutable.

[froschdesign]

We have to explicitly define all possible values for the filtering - input and ouput. Otherwise, we can not write the full documentation and all required unit tests.

Also DateTime to DateTime and similarly for immutable.

This means:

• DateTime to DateTime (new object, $immutable === false)
• DateTime to DateTimeImmutable (new object, $immutable === true)
• DateTimeImmutable to DateTime (new object, $immutable === false)
• DateTimeImmutable to DateTimeImmutable (new object, $immutable === true)

[gszy]

We can throw an InvalidArgumentException if the user provides something other than DateTimeInterface|string. The user can provide a valid string that at the same time (ahem) is not a valid datetime, but it’s probably Date Validator’s responsibility.

Anyway:

• DateTime → DateTime
• DateTime → DateTimeImmutable
• DateTimeImmutable → DateTime
• DateTimeImmutable → DateTimeImmutable
• string → DateTime
• string → DateTimeImmutable

[froschdesign]

@gscscnd

We can throw an InvalidArgumentException if the user provides something other than DateTimeInterface|string.

No exceptions are allowed during the process of filtering. If the given value can not be handled by the filter, the value should be returned unfiltered.

• DateTime → DateTime
• DateTimeImmutable → DateTimeImmutable

Does the filter create a new object each time or will the same object returned?

---

Can you describe the typical use case for this filter? Thanks!

[gszy]

No exceptions are allowed during the process of filtering. If the given value can not be handled by the filter, the value should be returned unfiltered.

🆗, will fix that. (Current code doesn’t throw exceptions explicitly, but setting $value to int will surely cause the DateTime constructor to throw.)

• DateTime → DateTime
• DateTimeImmutable → DateTimeImmutable

Does the filter create a new object each time or will the same object returned?

Returns the same instance.

Can you describe the typical use case for this filter? Thanks!

I’ve got a form (or any array of data, for that matter) with a datetime­‑like input and an entity with a datetime­‑like property. I setup an InputFilter with a Date validator and a DateTime filter. The input array contains 2019-04-25T08:02 (string) and the (hydrated) output object has instance of DateTimeInterface.

[froschdesign]

@gscscnd

The input array contains 2019-04-25T08:02 (string) and the (hydrated) output object has instance of DateTimeInterface.

If you use zend-hydrator already then you can use Zend\Hydrator\Strategy\DateTimeFormatterStrategy to get the desired result. Have you tried this strategy?

https://docs.zendframework.com/zend-hydrator/v3/strategy/#zend92hydrator92strategy92datetimeformatterstrategy

[gszy]

Well, I didn’t know about it. Thanks for the pointer!

[weierophinney]

This repository has been closed and moved to laminas/laminas-filter; a new issue has been opened at laminas/laminas-filter#1.

[weierophinney]

This repository has been moved to laminas/laminas-filter. If you feel that this patch is still relevant, please re-open against that repository, and reference this issue. To re-open, we suggest the following workflow:

• Squash all commits in your branch (git rebase -i origin/{branch})
• Make a note of all changed files (`git diff --name-only origin/{branch}...HEAD
• Run the laminas/laminas-migration tool on the code.
• Clone laminas/laminas-filter to another directory.
• Copy the files from the second bullet point to the clone of laminas/laminas-filter.
• In your clone of laminas/laminas-filter, commit the files, push to your fork, and open the new PR.
  We will be providing tooling via laminas/laminas-migration soon to help automate the process.