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