Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128609
Message-ID: <509C95E1-75FA-4D3E-A94E-636C33BCEB30@nicksdot.dev>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_0A425451-B775-4829-81CA-912032C48507"
Precedence: list
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\))
Subject: Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules
Date: Wed, 3 Sep 2025 18:26:51 +0700
In-Reply-To: <95ff868ebdb1e7ee4d99e5f07ada6a3f@bastelstu.be>
Cc: Thomas Nunninger <thomas@nunninger.info>,
 internals@lists.php.net
To: =?utf-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
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>
 <95ff868ebdb1e7ee4d99e5f07ada6a3f@bastelstu.be>
From: php@nicksdot.dev (Nick)


--Apple-Mail=_0A425451-B775-4829-81CA-912032C48507
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 2. Sep 2025, at 20:24, Tim D=C3=BCsterhus <tim@bastelstu.be> wrote:
>=20
> Hi
>=20
> Am 2025-09-02 13:43, schrieb Thomas Nunninger:
>> very legally inspired
>=20
> 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.
>=20
>> I'd say, there's no real issue about an additional/missing hour (or =
two) due to DST changes.
>=20
> Yes, that makes sense to me.
>=20
>> For extending the voting periods I'd stay with days as other values =
have similar issue and make calculations (slightly) harder.
>=20
> My suggested decreased =E2=80=9Chour values=E2=80=9D with the 8 hour =
leeway would just work when keeping the =E2=80=9Cday value=E2=80=9D in =
mind: If I just take the same hour+minute X days in the future, then I'm =
definitely over the required hours.
>=20
>> 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?
>=20
> 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 =E2=80=9Cminor =
miscalculation=E2=80=9D? Is it 1 hour? 2 hours? See how we're back to an =
hour-based definition?
>=20
> 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.
>=20
> Best regards
> Tim D=C3=BCsterhus

I just want to throw in that this sounds fairly easy to automate.=20
There is already a checkbox "Minor Changes=E2=80=9D when editing the =
RFC.
This means, the timestamp from the last major change can be used to =
simply display a =E2=80=9Cvoting allowed earliest at=E2=80=9D time.
For the voting, there could be another checkbox for =E2=80=9Copen =
voting=E2=80=9D. Which could validate the period, before actually =
allowing it.

Cheers
Nick=

--Apple-Mail=_0A425451-B775-4829-81CA-912032C48507
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;"><br =
id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote =
type=3D"cite"><div>On 2. Sep 2025, at 20:24, Tim D=C3=BCsterhus =
&lt;tim@bastelstu.be&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div><div>Hi<br><br>Am 2025-09-02 =
13:43, schrieb Thomas Nunninger:<br><blockquote type=3D"cite">very =
legally inspired<br></blockquote><br>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.<br><br><blockquote type=3D"cite">I'd say, there's no real =
issue about an additional/missing hour (or two) due to DST =
changes.<br></blockquote><br>Yes, that makes sense to =
me.<br><br><blockquote type=3D"cite">For extending the voting periods =
I'd stay with days as other values have similar issue and make =
calculations (slightly) harder.<br></blockquote><br>My suggested =
decreased =E2=80=9Chour values=E2=80=9D with the 8 hour leeway would =
just work when keeping the =E2=80=9Cday value=E2=80=9D in mind: If I =
just take the same hour+minute X days in the future, then I'm definitely =
over the required hours.<br><br><blockquote type=3D"cite">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?<br></blockquote><br>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 =E2=80=9Cminor miscalculation=E2=80=9D? Is it 1 hour? =
2 hours? See how we're back to an hour-based definition?<br><br>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.<br><br>Best regards<br>Tim =
D=C3=BCsterhus<br></div></div></blockquote></div><br><div>I just want to =
throw in that this sounds fairly easy to automate.&nbsp;</div><div>There =
is already a checkbox "Minor Changes=E2=80=9D when editing the =
RFC.</div><div>This means, the timestamp from the last major change can =
be used to simply display a =E2=80=9Cvoting allowed earliest at=E2=80=9D =
time.</div><div>For the voting, there could be another checkbox for =
=E2=80=9Copen voting=E2=80=9D. Which could validate the period, before =
actually allowing =
it.</div><div><br></div><div><b>Cheers</b></div><div>Nick</div></body></ht=
ml>=

--Apple-Mail=_0A425451-B775-4829-81CA-912032C48507--