Ben,

In the cases where you need a "then" clock, the same interface could be
used with a mock implementation that returns a set time.


--
Woody Gilk
https://www.shadowhand.com


On Wed, Apr 20, 2022 at 4:17 PM Ben Peachey <benpeac...@gmail.com> wrote:

> Hi all!
>
> I have a question regarding the ClockInterface. I wasn't sure if I should
> reply to this thread or open a new one, so I hope this is okay....
>
> In the original email, Chris Seufert mentions
>
> > Its impossible to mock some calls to date and time without using a PHP
> extension to override the current time & date.
>
> I've run into this in the past as well (for instance, using TimeCop to
> "freeze" time in tests). An intermediate (such as the proposed interface)
> would be very much welcome!
>
> The proposal states the interface provides "basic operation to read the
> current time and date from the clock".
>
> Has there already been talk of support in the interface (or a separate
> interface) for non-now time? If so, can someone point me to where I can
> read up on that?
>
> My reason for asking is that, having an interface for the one but not the
> other (i.e. for an interface for "now" but not for "then"), would
> eventually lead to still needing TimeCop (or similar) for the "then" cases.
> (Which I would obviously like to avoid, if possible).
>
> Greeting,
> Ben.
>
> On Saturday, 30 October 2021 at 15:37:46 UTC+2 daniel...@gmail.com wrote:
>
>> I had experience with such type of time provider (with interface) and we
>> realized that it's very impractical. At first, it looks cool: injecting
>> Clock which may be frozen here and regular there (integration tests with
>> real DI-container, not unit tests), but clock is singleton by its nature.
>> Moreover, sometimes you need time in value objects, e.g. `Uuid::v1()` or
>> domain entities and injecting service to them looks pretty awful.
>>
>> I suggest concrete class like
>> ```
>> final class Clock
>> {
>>     public static function setup(Closure $clock): void
>>     {
>>         // ...
>>     }
>>
>>     public static function now(): DateTimeImmutable
>>     {
>>         // ...
>>     }
>> }
>> ```
>> Concrete class is still fixes the interoperability problem and looks more
>> practical.
>>
>> On Saturday, October 23, 2021 at 10:31:09 PM UTC+3 and...@heigl.org
>> wrote:
>>
>>> Hey Larry, Hey List:
>>>
>>> On 15.09.21 19:24, Larry Garfield wrote:
>>> > On Mon, Sep 13, 2021, at 10:15 AM, Andreas Heigl wrote:
>>> […]
>>> >>
>>> >> [1]
>>> >>
>>> https://andreas.heigl.org/2016/12/22/why-not-to-convert-a-datetime-to-timestamp/
>>> >
>>> > That article is the most compelling argument I've heard yet for not
>>> forcing the return to UTC. An abridged version of the same point should be
>>> included in the metadoc.
>>>
>>> Done so via https://github.com/php-fig/fig-standards/pull/1257.
>>>
>>> I'd be happy about a review and an eventual merge.
>>>
>>> Cheers
>>>
>>> Andreas
>>>
>>> --
>>> ,,,
>>> (o o)
>>> +---------------------------------------------------------ooO-(_)-Ooo-+
>>> | Andreas Heigl |
>>> | mailto:and...@heigl.org N 50°22'59.5" E 08°23'58" |
>>> | https://andreas.heigl.org |
>>> +---------------------------------------------------------------------+
>>> | https://hei.gl/appointmentwithandreas |
>>> +---------------------------------------------------------------------+
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to php-fig+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/15f7d549-2503-4955-ac5e-23ad504ca2a4n%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/15f7d549-2503-4955-ac5e-23ad504ca2a4n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAGOJM6%2BqQ0HdnzpirY8hEsNx%2BKkU2E_07kXtpdt6qAY5M2j7vA%40mail.gmail.com.

Reply via email to