Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128606
Message-ID: <a5c92b61-ca74-4abd-87fc-4acfe692ec8f@nunninger.info>
Date: Tue, 2 Sep 2025 13:43:30 +0200
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules
To: internals@lists.php.net
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>
Content-Language: en-US
In-Reply-To: <9dc7f8f30e9237e6bf390fed61c1e972@bastelstu.be>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
UI-OutboundReport: notjunk:1;M01:P0:ohUpKGyUfwU=;REb1DCNp5oqm/zKLl17fM0HHT1w
 M53dDS00MDQjKFKMfqLgTzZBb6Eq9izVyeDO+BM5JFMUEitugkbBQ/RRAvZCXw3dhDWVuK5k9
 2JKzrKy2wiE0zv6kI/bNL+U+TB3taVAopOHWj9PZqBvADLWZvd9sH8siPDk4ejK3ILsVX4v1T
 jVBI30EKO5cTkUJK65Wr71cVcUiRH1vUmOlXG3mJh4qHTCf3lJ5fJvUnt9kf4aNHVgB9n0FDM
 yVz48fESz2Y6OLgU7Vuru8MDgkm27sLJqg3CsK56ksj4VnW0+3y7H3EgBVIrR7svcS2I90jb6
 l+Ns3g2oQWldGQlMyB5A08lWQD3Pfuu5HWhhIh16FcAZtiRWjfQp9mRirTBcEsChApIqmgWvF
 JXOme6rA6aBNdrMEOMmjH3tIyp3/a9VNohRjj65KSHoC6HBQawO+GhB5sN1hLw5IsXW42XHO+
 zhOneG3Kxm/uoGbVhSKK3nqlgdnPawiYNk2RFBFhlUgkbxnLwDzkPelN998PCjfDPaaySKN65
 Ek9nC6fsWRIiWEHEDxYLth9O7W1j+2pLFRC38UdjV22DcrVItaj64RdDhiZmECh20/SRPO1e4
 Aio4xFRrSBNopI+j3P+RrK9AQ+whFBX54TvExgDiZizHoMZqpnJ/4psj3TRCPUALZ4uGFaOtl
 uARc3OKN9D/Bcgsj/kAUxCyPnL2O5YT5+pWEka5rKy1iYprs/ZMV54bLpzclnX08cQYEPMp7t
 fANahuBukC7eiDbWf9R4YI/T6GlWz/+PZdtMfbarS489g1EfBOkAFE9dR155ScIQg9Oq4Jz7U
 VxEANA24iM1D6eK29HSHKB7EKAeKSdAOfKtNN4AsnfIrNXixAKhAHxg79lZWqXKoY5wKl0Vi9
 F0d/6HMwfPosme9dRHya8Xq74IOWTRmdpA0kWEhqK3qlweHGDL8W4vukktp9+eAyo8bI+4dJH
 cyeBBlcvxgNEGz1pO1Hp2psLr4JkhC6qDPJu8XoakDHvwmyif6ibVypwchF6iTtXrBWcuA5Za
 TUD0Di+O7wIvIx6zud7Qqx3bNXpzQKooL58auu6ZPnricc9LWlnwngvONF+bHNZ2hgF5erkD3
 etLPb+KQto0pFzHD1WuTTDXTWMUjsagQaSfhCo+SQW/ymEfjg2l/OKlgjeUsgw8MSsibcQaaz
 EWVigp/NItyoyVsne2ZeDCzYDJ8iNx8nQpst3MaBWyTfLPgY49/quOSljpojDOcDvGQb3/X1O
 BhbbWaTOM4sFjnZ9TJCG53I2CGGFtUlgMcVr2m4YOuPsBfORMOQupPWj84U7KzOL0ix8yN013
 A1185Ral7cCVvXJEc6yYRXubd90lRY0Pz5bpmfMmcvTkOg+fRtyF2tWeILdbZElolgmwe4TTJ
 0SQghrOnxUag97E7hLFubS2Q4rAFmVZZX5Wrk3hfihXyB3zyEJRt0MnhkGRE/9Sisbomr03Un
 n0BKAGqV3oyYp+mRSJ0libsJhdxN1m3iMhXWZqHFvZK16OrkWuQnL60whFWgVXsx/xxniG4hh
 sAUdmthGuqMQXa8rBu2SSI8MauotDB49yRU24ideYOkl8b7jFVzlVyUxxbw/L44YxJu3l+QoE
 xUDpw0wWXrfm+YmnXjUaBwy/uokbqxmPcA5NOxfXHDgueNAzVCySo3rOOFGw6FQ32eyj6OV+y
 jmwgrL9JB9idX6CnEI38ihAu90RT9F4+bimFVVRrtxqV+wu28A1FlzIOsBd3oT/Rw=
From: thomas@nunninger.info (Thomas Nunninger)

Am 02.09.25 um 12:41 schrieb Tim Düsterhus:
> Hi
> 
> Am 2025-09-01 15:50, schrieb Andreas Heigl:
>> While I understand the idea my nitpick to this was to not assume 
>> 86,400-second days. As the examples in the RFC explain quite 
>> understandable that the voting ends (earliest) at 16:00H when it 
>> started at 16:00 hours I would not put that into actual hours.
>> […]
>> In addition, adding 2 weeks to a datetime will add (usually) 14 days 
>> to the date but the time will stay the same anyhow.
> 
> That depends on the timezone. DST changes do not all happen at the same 
> time or day around the world, sometimes they do not happen at all. 
> Having a purely day-and-time-based definition is needlessly ambiguous, 2 
> days could be validly interpreted as everything between just over 24 
> hours (when the beginning of the period is at 23:59:59 of day 1 and the 
> end at 00:00:00 of day 3) and 49 hours (“same time across a DST change”).
> 
>> If we see that the number of hours elapsed is a reason to question the 
>> validity of a vote - and as far as I understand it that is what this 
>> is in essence trying to prevent - then in my opinion we have a 
>> different problem that is not going to be resolved based on the number 
>> of elapsed hours.
>>
> 
> Policy, like contracts, exist to make an agreement in preparation for 
> future situations where folks disagree. While I certainly hope that we 
> won't need to be pedantic about the policy and that everyone is acting 
> in good faith, I want to avoid needing to discuss what “2 weeks” means 
> in a situation that is already stressful for everyone involved due to 
> other circumstances. Having a clear definition in the policy makes it 
> easier to cut that discussion short.
> 
> However you are right that it's easy to accidentally violate the “hour 
> rule” in case of DST changes. What about slightly decreasing them to 
> give some wiggle room to account for varying schedules and DST / 
> timezone changes?
> 
> - 2 days: 40 hours (1 full day + 16 hours)
> - 1 week: 160 hours (7 full days + 16 hours)
> - 2 weeks: 328 hours (13 full days + 16 hours)

When reading about the detailled hours in the PR, I was a little bit 
disturbed about the exact calculation of hours. It looked overly 
pedandic (read: very legally inspired) to me.

I just checked very few of the latest voting anouncements. Most times 
some kind of relation to UTC was provided.

I'd say, there's no real issue about an additional/missing hour (or two) 
due to DST changes.

Assuming the end time is clearly defined and someone miscaluclated it 
because of DST changes that should not be an issue in a reasonable time 
frame. (Discussing about a voting result because of such a minor 
miscalculation found later wouldn't be nice either.)

For extending the voting periods I'd stay with days as other values have 
similar issue and make calculations (slightly) harder.

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?

Best regards,
Thomas