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)
Best regards
Tim Düsterhus
