Hey Larry, Hey All. On 13.09.21 16:26, Larry Garfield 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/818850995186171918I 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.
We've discussed that back and forth as well. In the end there are two reasons why we decided to ignore timezones:1. We can not enforce a specific timezone via the return type. The only thing we *can* enforce is that it is a DateTimeImmutable object. But we can not enforce what timezone it is set in. Additionally no matter what timezone it is set, it will anyhow describe a specific point in time - which is what we care about in the end. If the Busines-Logic needs that in a specific timezone it is also the task of the business-logic to ensure that.
2. Depending on the Clock that is uses one can make sure that only DateTimeImmutable objects of a specified timezone are returned on calling `ClockInterface::now()`. So there can be an implicit contract to always have a DateTimeImmutable Object with a defined timezone.
Besides those two reasons there is usually only a conversion into a certain timezone necessary when displaying the data. That is the only reason to actually modify the timezone. If you need the timestamp you can always use `DateTimeImmutable::getTimestamp()` and per definition that will always be in UTC. so there is no need to actually modify the timezone to UTC before.
All that made it reasonable to ignore the timezone aspect.
Does that clarify the case?
Cheers
Andreas
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@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/4c3c4a4a-7be4-27fb-f879-2e4d5f7ac366%40heigl.org.
OpenPGP_0xA8D5437ECE724FE5.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
