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
