On Wed, Sep 23, 2026, at 12:29 PM, Tim Düsterhus wrote: >> - Why is a compare() method needed if Instant already supports <, >, >> etc? > > API consistency with Duration. Also a method has proper typing and works > with first class callables / PFA. Duration specifically had this > example: > > usort($durations, Duration::compare(...));
Ah, valid use case indeed. Thanks. > For custom formats, in particular formats with an implied timezone, > you’ll need to wait for the future scope “Instant + Timezone” class. I am indeed waiting with baited breath. (That will be the DateTimeImmutable replacement, essentially, yes?) >> My big issue, though, is context. This is very clearly part 2 of N, >> which is fine. Presumably you and Derick have a roadmap between you of >> what the end goal looks like and the moving parts that will be added, >> even if it's in steps. But that's not documented anywhere other than >> your heads, AFAIK, and the future scope section as currently written is >> barely 3 of N, and not in detail. >> >> I realize that designs change over time as they're implemented, which >> is totally fine, and all the details of later steps have likely not >> been worked out yet, which is also totally fine. But I still need to >> see the big picture, at least at a coarse resolution, to understand >> this RFC in context. Things that we feel are missing may be missing >> not out of incompleteness but "that's step N+3", which may be a >> perfectly good design but that's not at all apparent. >> >> I would strongly urge you to post (probably as an RFC page, even though >> it's not a full RFC) an overarching roadmap/plan for PHP Time TNG, so >> we can get a sense of where we're going. That will allow us to see >> each RFC in its appropriate context, and clearly note when things have >> been pushed to later that "later" is defined and documented. (Eg, the >> FrozenClock idea.) > > Each part of the series is intended to stand on its own and to be > complete enough to be usable for production use cases rather than just > toy examples. The end goal is to model (all) real-world concepts of time > and the focus of each RFC text is explaining that concept and how it was > modeled. If you expected the modeling to cover something and the RFC > doesn’t mention it (“I expected it to do X, why doesn’t it?”), we failed > at that explanation and I recommend raising the issue on the mailing > list. > > The evolution of the new date and time API is also not linear, but > rather a graph connecting the various concepts that can be worked on in > any order, as long as the dependencies are satisfied. To get a rough > idea of where we’re heading you can take a look at java.time and > JavaScript’s Temporal. Then please share the graph. There is nowhere right now that someone can go to canonically see "oh, they are planning to add a new timezone object and a new DateTimeImmutable replacement later, too. Good to know." I know you and I have discussed this before, but I am going to keep riding this horse: You clearly have a roadmap in your heads. Share it. At whatever level of granularity it exists, share it. We need that sort of context., It builds trust in the process and in the people that are working on it. Everyone understands it's not a promise, but a communication mechanism, and a very important one for this sort of effort. --Larry Garfield
