On 13.09.21 16:38, Woody Gilk wrote:
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/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.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.
Nope.If you are actually using timezones (Timezone type 3) then there is no need to convert to UTC. On the contrary, it might be a bad idea to convert everything to UTC or to use only UTC[1].
The second reason why that would not be a good idea is that we can not guarantee that a DateTimeImmutable object returned by `ClockInterface:now()` is actually with timezone UTC.
And even if so: 12:00:00 UTC, 14:00:00+02:00 and 10:00:00-02:00 are all different expressions of the same point in time. And `DateTimeImmutable::now()` returns something that describes a point in time. If the busines-logic needs that point in time also in a specific timezone, then it is the task of the business-logic to ensure that.
Cheers AndreasPS:Personal opinion: From what I have seen so far, a lot of the hassle with timezones comes from people trying to do something with it while not understanding it and thereby making it (much) worse... ;-)
[1] https://andreas.heigl.org/2016/12/22/why-not-to-convert-a-datetime-to-timestamp/
-- 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 .
--
,,,
(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/e2e6d0fb-58c3-aae9-d157-56ed530fcce7%40heigl.org.
OpenPGP_0xA8D5437ECE724FE5.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
