On 15.09.21 19:24, Larry Garfield wrote:
On Mon, Sep 13, 2021, at 10:15 AM, Andreas Heigl wrote: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 Andreas PS: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/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. That the type system cannot guarantee that it's in UTC is irrelevant. Specs can and do require all kinds of things above and beyond what the type system can enforce. That's the purpose of a spec, not just an interface package. :-) By analogy, though, 1 m, 1000 mm, and 39.370 inches all represent the same length. If I'm asking some service for a length, though, my business logic generally does care about the units. Timezone is, as I conceptualize it, analogous to units in this case.
Yes. And as with the lengths your busines logic should make sure that the numbers as well as the unit match your expectation. Otherwise you might crash a mars lander[1].
Applied to timezones: When your busines-logic expects the DAteTimeImmutable object to be in a certain timezone, you need to make sure that it actually *is* in that expected timezone.
Therefore I'd rather not have any implicit (despite it being documented in a specification) rules about what kind of state a DateTimeImmutable object is in.
The explicit contract that the interface can provide, is that it returns a DateTimeImmutable object. With a set timezone. And it's up to your business logic then to make sure that that matches your codes expectations.
And yes: We might have a different view here on what a spec might and might not be able to do. I rather play the *very* safe card ;-)
Cheers Andreas [1] https://www.simscale.com/blog/2017/12/nasa-mars-climate-orbiter-metric/ -- ,,, (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/ac8b692b-d2b9-e320-697d-762b353e4b64%40heigl.org.
OpenPGP_0xA8D5437ECE724FE5.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
