On Mon, Sep 13, 2021 at 9:26 AM Larry Garfield <la...@garfieldtech.com> wrote:
> On Sun, Sep 12, 2021, at 12:53 PM, Andreas Heigl wrote: > > Hey all. > > > > Some months of work have past for the Working Group for PSR-20 > > (ClockInterface). > > > > By now our idea of the interface has stabilized, a lot of internal > > decissions have been made and a lot of discussion with different people > > – especially maintainers of different clock implementations – have been > > done and had their influence on the interface and on the meta-document > > associated with it. > > > > Time to open up the discussion to the list and to external feedback. > > > > Please give feedback regarding the Interface[1] and the > > Meta-Document[2]. Either on the PSR-20 Channel on Discord[3], via the > > mailinglist or via PullRequests against those two documents. > > > > Cheers > > > > Andreas > > > > [1] > > > https://github.com/php-fig/fig-standards/blob/master/proposed/clock-meta.md > > [2] > https://github.com/php-fig/fig-standards/blob/master/proposed/clock.md > > [3] https://discord.com/channels/788815898948665366/818850995186171918 > > I filed a small PR with some typo fixes. Nothing major. > > Overall I like the simplicity of it. My main concern is, unsurprisingly, > around the timezone question, and usability. > > Right now, if I want "now" I can just call `new DateTimeImmutable('now', > new DateTimeZone('whatever'))` directly. It's a single call. > > With the proposed interface, I will virtually always need to create TWO > DTI objects; one that gets returned by now(), and one returned by calling > setTimezone() on it. (Because I never trust what the system timezone is > set to, and neither should you.) That is slightly less performant, and > also clunkier feeling. And that means people will forget to do it. > > I fear that, in its current form, we'll end up with a lot of people > assuming the timezone they get back from now() is reasonable, when in fact > it's not defined at all, and end up with subtle bugs. > I feel like the timezone concerns are not as dire as they might initially seem, because: 1. It is easy to wrap this interface with a local implementation that will always return the date object in (eg) UTC. It's about 3 actual lines of code. 2. In environments that we (really do) control, we can set `date.timezone` and not have to think about it again. That being said, I think it would also be reasonable for `ClockInterface::now()` to ALWAYS return a date in UTC timezone. That would create a stronger definition and eliminate most concerns about time zones. -- Woody Gilk https://www.shadowhand.com > > --Larry Garfield > > -- > 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/f74c10e6-79ea-4113-913c-b79ded8407d3%40www.fastmail.com > . > -- 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/CAGOJM6J62LT-Q6QJW5_RbghjSzSQqij%2BOn6QVTL5zi%2B4eQmb1Q%40mail.gmail.com.
