Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128608
Precedence: list
MIME-Version: 1.0
Date: Tue, 02 Sep 2025 15:24:02 +0200
To: Thomas Nunninger <thomas@nunninger.info>
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules
In-Reply-To: <a5c92b61-ca74-4abd-87fc-4acfe692ec8f@nunninger.info>
References: <53cdbf5b-7c6e-4ba1-9987-332634cab527@bastelstu.be>
 <4624748F-0C62-4E3C-81D0-5CDC56FEC55F@nicksdot.dev>
 <85e7e7ee-87b3-46ac-8379-4ab9be45eae5@heigl.org>
 <9dc7f8f30e9237e6bf390fed61c1e972@bastelstu.be>
 <a5c92b61-ca74-4abd-87fc-4acfe692ec8f@nunninger.info>
Message-ID: <95ff868ebdb1e7ee4d99e5f07ada6a3f@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

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