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.
--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/fbe7293c-f2d3-4367-b3c9-d35d9fbc7a04%40www.fastmail.com.
