用户:Sanmosa/论述/以星期为时间单位
本页简而言之:撰文人意欲通过此文表达现时中文维基百科部分事项的期限以长度不固定的时间单位计算的不当性。 |
现时,中文维基百科对于部分事项的期限以年、月等时间单位计算,然而年、月等时间单位的长度并不固定,如一年的长度可以是365日或366日,而一个月的长度可以是28日至31日,因此以年、月等为计算事项的期限的时间单位会引起长度不一的不公问题,而另一方面,以年、月等为时间单位计算期限的事项一般需要较长的时间期限,而仅以日数计算事项的期限会导致计算不必要地复杂。因此,本文提议以长度固定的星期为计算需时较长的事项的期限的时间单位,以弥消长度不一的不公问题。
封锁期长度
[编辑]现时,中文维基百科里较长的封锁期一般长若干月或若干年,然而年、月等时间单位的长度的不同引致了名义上长度同等的封锁期的实际长度并不相等,如长度为3年的封锁期的实际长度可以为1095日或1096日,长度为6个月的封锁期的实际长度可以为181日至184日,实际长度的不相等又继而引致了不公问题。
WP:斐波那契封禁称斐波那契数列中的每项是前项的黄金比例倍,并主张基于斐波那契数列设定的封锁期长度为“最温和的长度”。这对于数值较大的项而言适用,因为这些斐波那契数列项与其前项的倍数差的数列极限会随着数值的增大而收敛趋近黄金比例:
这点也同样适用于卢卡斯数列:
然而,这对于数值较小的项而言不适用。如斐波那契数列中的第三项(即2)是第二项(即1)的2倍,而第四项(即3)则是第三项(即2)的1.5倍。因此,就数值较小的项而言,斐波那契数与其前项的倍数差是不稳定的。这点也同样适用于卢卡斯数列,如卢卡斯数列中的第三项(即3)是第二项(即1)的3倍,而第四项(即4)则是第三项(即3)的1.333倍。因此,就较短期的封锁而言,基于斐波那契数列设定的封锁期长度为“最温和的长度”的结论并不稳妥。
较稳妥的做法应该是以每个数列项与其前项的倍数差完全(而非趋近)固定的数列设定封锁期长度,基于这种数列设定的封锁期长度为“最温和的长度”的结论稳妥与否视乎该固定的倍数差本身合理与否。由于本文主张以星期为计时单位,因此这里给出一种可行的方案替代基于斐波那契数列设定封锁期长度:以1/8星期(即7/8日、21小时)为基本的封锁期长度,而每次再犯的封锁期长度为原封锁期长度的2倍,即:
- (以星期数计)
- (以日数计)
- (以小时数计)
其中n是犯某特定错误的次数,首次为1、第二次为2、第三次为3,如此类推。
讨论时间
[编辑]WP:共识#提案讨论及公示时间曾一度规定“互助客栈中的提案仅在7日内无新留言时或已讨论达1个月后,方可在已取得共识的前提下公示”,然而如上所言,月的长度并不固定,这引致了名义上长度同等的讨论期的实际长度并不相等,并又继而引致了不公问题。“1个月”的条件后来被调整为现行的“30日”,然而30日的设定并不易记忆,因为某一特定日的30日后可以是未满1个月、刚好满1个月或逾1个月,这使某一特定日与其30日后在一个星期与一个月里的日次(即星期几、某月几日)并不相同。因此,这里提议所有以“1个月”或“30日”等为时间长度的条件应调整为4星期(即28日),这使完结日与开始日在一个星期里的日次得以保持一致,便利记忆。