> On 2. Sep 2025, at 20:24, Tim Düsterhus <[email protected]> wrote: > > Hi > > Am 2025-09-02 13:43, schrieb Thomas Nunninger: >> very legally inspired > > Well, yes. That was the goal. RFCs in general should describe the proposal in > way that does not leave any ambiguity about what exactly is being proposed, > so that everyone is able to make an informed decision. And that extends to > the policy documents. The policy documents effectively are contracts that > govern how the PHP project wants to develop the language and how it wants to > make decisions. > >> I'd say, there's no real issue about an additional/missing hour (or two) due >> to DST changes. > > Yes, that makes sense to me. > >> For extending the voting periods I'd stay with days as other values have >> similar issue and make calculations (slightly) harder. > > My suggested decreased “hour values” with the 8 hour leeway would just work > when keeping the “day value” in mind: If I just take the same hour+minute X > days in the future, then I'm definitely over the required hours. > >> Would it be an alternative to add some general sentence about using UTC time >> and that calculations should use UTC, but if there are some minor >> miscalculations (e.g. due to missed DST changes) that is acceptable? > > I believe that defining what a day is, is more complex than specifying an > hour value - even when only considering UTC. To use my previous example: Is > 2025-09-02 23:50 UTC until 2025-09-04 02:00 UTC two days? The difference > between 4 and 2 is 2. Also what is a “minor miscalculation”? Is it 1 hour? 2 > hours? See how we're back to an hour-based definition? > > I'm in Europe/Berlin, which makes calculating in UTC reasonably easy for me > to do, since my waking hours are generally all within the same UTC day. This > is different for folks outside of Europe, since they regularly cross UTC days > within their waking hours, making it more likely for (significant) errors to > sneak in. > > Best regards > Tim Düsterhus
I just want to throw in that this sounds fairly easy to automate. There is already a checkbox "Minor Changes” when editing the RFC. This means, the timestamp from the last major change can be used to simply display a “voting allowed earliest at” time. For the voting, there could be another checkbox for “open voting”. Which could validate the period, before actually allowing it. Cheers Nick
