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
