維基百科討論:機器用戶
Flood flag
[編輯]現時很多機械人操作要求編輯被保護的頁面,但目前zhwiki沒有授予機械人管理員權限的先例,造成了很多操作只能用管理員賬號跑,從而導致無法掛上bot flag進而刷掉整版的最近更改。因此,在下想提請在本地啟用目前元維基使用的m:Flood flag。
這樣管理員可以在執行重複性的、不適合人類進行的操作時,可以給自己加上Flood flag,從而在機械人腳本中提交的bot標記將產生效果並在最近更改中默認隱藏(不會影響通過常規編輯界面做出的編輯)。按照目前元維基的現狀,管理員應當僅在即將進行上述操作時加上flag,在進行完成後即行去除。對於該項權限的濫用應當等同於對其它管理員權限的濫用。
在下認為這種方式優於向機械人授予管理員權限或要求管理員每次都向行政員索要機械人權限。故在此提交社群討論,歡迎提出意見。以上。--Jimmy Xu talk·201 2010年11月18日 (四) 13:54 (UTC)
- (+)贊成。--菲菇@維基食用菌協會 2010年11月18日 (四) 14:10 (UTC)
- (*)提醒,已將方針頁翻譯完成,請見WP:機械人用戶。--Jimmy Xu talk·201 2010年11月19日 (五) 03:29 (UTC)
- (-)反對:請先明確使用機械人的義務再說。君不見User:Shizhao老大認為社群不是對他的機械人授權,而是對他授權,所以他愛怎麼用機械人就怎麼用,不必再申請。而且弄出一堆保護頁的不正是管理員自己嗎?管理員自己太隨便,搞到自己不方便,現在又想擴大權限,結果便是更加隨便。--百楽兎 2010年11月19日 (五) 05:17 (UTC)
- (+)贊成:另外請百樂兔注意,你所說的「管理員自己太隨便,搞到自己不方便」完全是你對此功能的誤解。這個功能是讓大家再看最近更改的時候,可以不會看到一大堆其實是由機械人跑的保護頁面定期維護更新,受益的不是管理員而是整個社群(想在最近更改裏看這些更新的話只要將機械人更改的部分改為顯示即可)。閣下提出的機械人授權問題是另外一回事,請不要攪在一起。--祥龍 (留言) 2010年11月19日 (五) 05:37 (UTC)
- (:)回應:受益?一些管理員仍搞不清楚機械人的操作義務,這個方針又任由管理員自己定義所謂「大量重複性、無爭議的編輯」,並可透過這個Flood flag的方便工具將自己有爭議的機械人的所做所為進一步隱藏起來、減少被社群監測到機會,這就是你所謂整個社群受益+我對此功能的誤解+我把事情攪在一起?中文維基百科的參與者真的很有才。--百楽兎 2010年11月24日 (三) 05:12 (UTC)
- (:)回應:看來閣下的確還是沒有弄懂這個功能到底是在作什麼。這個功能的用途就是將是機械人作的修改就標明為是機械人的修改,而不是因為得透過管理員帳號才能修改而誤認為是由管理員本人進行的修改。另外現在機械人作的修改本來就是預設成隱藏的,此一修改會影響到的只有受保護頁面,而基本上會經常需要修改的受保護頁面多半與首頁有關,例如{{DYK}},若是受到更改很快就會被社群發現。至於其他的受保護頁面不外乎是經常被使用的模板與發生編輯戰的頁面,亦是容易受到社群注意的情形。由此看來,並不存在什麼進一步的問題,閣下的質疑根本站不住腳。--祥龍 (留言) 2010年11月24日 (三) 08:48 (UTC)
- (:)回應:看你的回應真是浪費我時間。我在說什麼,你根本沒有懂而且也不想懂。--百楽兎 2010年11月25日 (四) 07:44 (UTC)
- (:)回應:以上的話也可以用在你身上。我已經反駁了你立論的依據,你說的「減少被社群監測到的機會」的問題根本不存在。這個功能的唯一用途就是讓是機械人作的動作就標示為機械人,是管理員本人作的動作就標示為管理員本人做的,僅此而已。事實情況是這些編輯一直在做,而這些其實是由機械人跑的編輯會在最近更改裏顯示成是管理員所做的編輯,造成洗版。如果閣下真要徹底監視機械人的話,那麼應該要求將機械人所做編輯在最近修改裏預設成顯示,而非反對正確標明做出動作是人還是機械人。由此可見,你所要反對和提出的意見根本就弄錯了對象。--祥龍 (留言) 2010年11月25日 (四) 13:02 (UTC)
- (:)回應:看你的回應真是浪費我時間。我在說什麼,你根本沒有懂而且也不想懂。--百楽兎 2010年11月25日 (四) 07:44 (UTC)
- (:)回應,如管理員使用此權限隱藏爭議編輯則可視為濫用權限。--Jimmy Xu talk·194 2010年11月25日 (四) 12:22 (UTC)
- (:)回應:看來閣下的確還是沒有弄懂這個功能到底是在作什麼。這個功能的用途就是將是機械人作的修改就標明為是機械人的修改,而不是因為得透過管理員帳號才能修改而誤認為是由管理員本人進行的修改。另外現在機械人作的修改本來就是預設成隱藏的,此一修改會影響到的只有受保護頁面,而基本上會經常需要修改的受保護頁面多半與首頁有關,例如{{DYK}},若是受到更改很快就會被社群發現。至於其他的受保護頁面不外乎是經常被使用的模板與發生編輯戰的頁面,亦是容易受到社群注意的情形。由此看來,並不存在什麼進一步的問題,閣下的質疑根本站不住腳。--祥龍 (留言) 2010年11月24日 (三) 08:48 (UTC)
- (:)回應:受益?一些管理員仍搞不清楚機械人的操作義務,這個方針又任由管理員自己定義所謂「大量重複性、無爭議的編輯」,並可透過這個Flood flag的方便工具將自己有爭議的機械人的所做所為進一步隱藏起來、減少被社群監測到機會,這就是你所謂整個社群受益+我對此功能的誤解+我把事情攪在一起?中文維基百科的參與者真的很有才。--百楽兎 2010年11月24日 (三) 05:12 (UTC)
- (+)支持--達師 - 147 - 228 2010年11月19日 (五) 13:58 (UTC)
- (+)支持,方便巡查員盯RC吧。--快龍☀此致敬禮 2010年11月19日 (五) 16:44 (UTC)
- (+)支持:但請不要運行有爭議的腳本。--蘋果派.留言 2010年11月20日 (六) 15:31 (UTC)
- (+)贊成,另外,我何時「認為社群不是對他的機械人授權,而是對他授權「?--百無一用是書生 (☎) 2010年11月22日 (一) 02:39 (UTC)
- (:)回應:
那看來是我們對bot要求上的理解差異了。我認為社群對bot的批準是出於信任而允許他的傀儡帳號擁有bot許可權,並出於善意推定相信這個用戶會妥善使用bot。而你則認為bot的每一項工作都要取得社群的信任,要有社群的批准才行。…--百無一用是書生 (☎) 2010年10月2日 (六) 11:53 (UTC) |
忙到連自己說過的話都忘了啊?--百楽兎 2010年11月24日 (三) 05:12 (UTC)
- 我的意思是相信這個用戶,才會對他的bot授權,對用戶授權又沒用,又不能讓他的bot帳號獲得bot權限--百無一用是書生 (☎) 2010年11月24日 (三) 09:10 (UTC)
- (:)回應:既然你認為社群沒有對你授權,你怎麼還敢擅自變更機械人獲得授權的工作呢?自相矛盾。--百楽兎 2010年11月25日 (四) 07:44 (UTC)
- (!)意見,同意以上的觀點。機械人的動作應該受到嚴格的限制,機械人的管理人不應擅自做出絲毫變更。115.160.157.41 (留言) 2010年12月8日 (三) 19:23 (UTC)
- (:)回應:既然你認為社群沒有對你授權,你怎麼還敢擅自變更機械人獲得授權的工作呢?自相矛盾。--百楽兎 2010年11月25日 (四) 07:44 (UTC)
- 我的意思是相信這個用戶,才會對他的bot授權,對用戶授權又沒用,又不能讓他的bot帳號獲得bot權限--百無一用是書生 (☎) 2010年11月24日 (三) 09:10 (UTC)
經一周討論,在下認為已達到共識,交Bugzilla。--Jimmy Xu talk·194 2010年11月25日 (四) 12:25 (UTC)
- (:)回應:又來了,作為正式方針可以這麼不正式就通過了喔?--百楽兎 2010年11月30日 (二) 01:37 (UTC)
- 建議先整理一下目前的機械人的任務。(上次百樂兔提出的意見的問題不知道修正沒有,反正我覺得這樣下去有一天終會出大亂)—Edouardlicn (留言) 2010年12月2日 (四) 04:18 (UTC)
完成--Jimmy Xu talk·187 2010年12月2日 (四) 14:35 (UTC)
現時此方針之中,標明只有管理員可以使用此權限,然而實際上並非只有管理員才會沖刷「最近更新」,非管理員亦會,尤其持有AWB使用權用戶。如果批量編輯屬於恆常,固然應該另開帳戶並申請機械人權限,但亦的確偶爾會有需要短期大量操作,所以普通用戶亦都應該可以在妥善監察情況下使用「機器用戶權限」。是故,現提請增訂以下條文至《機器用戶方針》。有請諸位定奪。
== 非管理員使用機器用戶權限 == 非管理員亦可短時間內使用機器用戶權限,然而需要有行政員或管理員監察下才可使用,以確保權限使用正確。用戶如有需要,應該在申請時列明工作內容為何,經[[WP:BAG|機械人審核小組]]成員或行政員審核後可取得權限。機器用戶權限不止適用於AWB使用權持有用戶,然後就AWB使用者而言,由於獲得此權限以後,可以轉為全自動操作。所以申請時必須述明是否轉為全自動操作,而若然轉為全自動操作,工作內容則必須符合[[WP:機械人方針|機械人方針]]第二節規定。載有機器用戶權限時,應該只進行預先獲批准操作。如果用戶在獲得權限時,進行未獲批操作,管理員可即時[[WP:BP|封禁]]。當操作完成時,用戶應及時至[[Special:用户权限]]移去權限。如果未有移除,行政員或管理員將會移去權限。
以上。--J.Wong 2017年6月23日 (五) 05:39 (UTC)
- (+)支持:個人是支持,權限申請時表示以認可該用戶,諾用戶不當使用(如那機器用戶作不當的編輯應當被審查是否合適權限)。另外應授予用戶使用完畢則可自行移除機器用戶,以利作其他一般編輯或討論。這部分也請考慮一下。--Zest 2017年6月23日 (五) 06:07 (UTC)
- (-)反對:超速的編輯需要申請機械人。--小躍(撈出記錄) 2017年6月24日 (六) 14:26 (UTC)
- 所以如君所言,管理員都不應該使用此權限?用戶之所以亦有機會需要使用此權限,乃因為就算現時已使用編輯過濾器規限AWB使用者每分鐘只可以作三次編輯,但當使用最高速度時一樣足以洗刷最近更新。機械人與機器用戶,兩種權限分工其實非常清楚,機械人權限是給予附屬帳戶,讓用戶處理恆常繁複工作,機器用戶權限是給予主帳戶,處理短期而繁複工作,其工作量應是數以小時計就能完成。而且該等工作應該只是簡單替換分類、模板等。此等工作使用AWB可以快速完成,但無疑亦是可以洗刷最近更新,阻礙正常巡查。難道要用戶經歷數以月計申請程序,然後去完成數以小時計工作?如此不成比例?兩組權限內容亦有明顯差異。而普通用戶因為本身沒有自帶「noratelimit」,某些動作速率仍然會受限;「apihighlimits」及「nominornewtalk」等權限亦是「機械人」才有,「機械人用戶」沒有。如果用戶只是打算用AWB進行簡單分類或模板替換,機械人有些權限對該用戶而言是根本多餘。
- 與其他編輯於IRC上討論後,認為機器用戶權限審核過程,應與機械人審核過程看齊,應讓機械人審核小組參與審核過程,此議亦合理,遂稍為修改上列提案。
- 以上。--J.Wong 2017年6月24日 (六) 16:14 (UTC)
- 傾向(+)支持,未見其弊。--⌬胡蘿蔔 BOARD · CHEM 2017年6月24日 (六) 19:25 (UTC)
- 可是忽然設想到一個可能:如果一個行事有爭議的良好用戶(比如曾經打編輯戰、加入疑似不中立內容,但非破壞者,亦有明顯貢獻)要作批量編輯,向BAG拿下了權限。在打算開始批量編輯前的一刻,該用戶突然想起自己涉及過的條目爭議已經冷卻好一陣子,便馬上加入自己一直想加的不中立內容,然後立即作批量編輯,完成後除權。這樣,他的濫用行為倒不是難以監察?--⌬胡蘿蔔 BOARD · CHEM 2017年6月24日 (六) 19:33 (UTC)
- 使用AWB修改的話摘要和位元數會非常相近,其中有誤會很明顯,因此提議授予時放至監督列表,使用時段的編輯紀錄可作檢查,任何惡意行為均需嚴懲。--Zest 2017年6月24日 (六) 19:44 (UTC)
- BAG成員、管理員或行政員可使用RTRC進行實時監察。--J.Wong 2017年6月24日 (六) 20:55 (UTC)
- (!)意見機器用戶就處於一種未達機械人的中間權限,機械人審核非常嚴謹,而AWB亦需達到用戶的行為為可信任,編輯修改無誤方可授權,兩者差別在於機械人是定時、長期的修改,AWB為短期,但也有大量修改的時候,為了避免洗刷近期變更,這是一項措施,但不管是那一種方法都要使該用戶了解並遵守使用機器用戶權限時不得作其他不屬於批量修改的編輯,以及批量修改爭議條目未取得共識時的禁封手段。--Zest 2017年6月24日 (六) 19:44 (UTC)
- (!)意見我們要注意,短期/一次性的編輯也可以帶來很大的破壞。無共識下更改分類就是一個很好的例子。為此,目前wp:botpol不但要求機械人申請者需要明確申報任務,而且對那些任務不會獲批也有明確的規定(見sec2.5)。然而,目前的草案並無上述的規定。這等於開放漏洞,讓申請者繞過BAG的監察。我們可以想像,日後可能會有人藉此繞過Special:濫用過濾器/45的限制。目前的條文在方方面面都沒有明確的規定,實在難以稱得上創設一項新制度。--Temp3600(留言) 2017年6月24日 (六) 20:11 (UTC)
- 注意AF45僅限建立條目,對已有條目的編輯不受限制。--A2093064#Talk 2017年6月24日 (六) 23:18 (UTC)
- (!)意見我們要注意,短期/一次性的編輯也可以帶來很大的破壞。無共識下更改分類就是一個很好的例子。為此,目前wp:botpol不但要求機械人申請者需要明確申報任務,而且對那些任務不會獲批也有明確的規定(見sec2.5)。然而,目前的草案並無上述的規定。這等於開放漏洞,讓申請者繞過BAG的監察。我們可以想像,日後可能會有人藉此繞過Special:濫用過濾器/45的限制。目前的條文在方方面面都沒有明確的規定,實在難以稱得上創設一項新制度。--Temp3600(留言) 2017年6月24日 (六) 20:11 (UTC)
- 已經修改草案,堵塞漏洞。分類及模板替換等細節將會在申請頁述明,以提醒申請者及管理人員。因為此等內容已經在其他方針敘明,所以此處則不贅。而的確《機械人方針》有要求申請者述明將進行工作為何,已在草案加入相關要求。因為當用戶獲得權限以後,使用AWB時,可以轉為全自動操作,符合《機械人方針》機械人定義,所以已述明申請時必須申明操作速度,及如果選擇全自動操作,則須符合《機械人方針》第二段。另外,亦參考《機械人方針》賦權管理員封禁用戶,如用戶進行未經批准操作。另外,亦參考上面用戶意見,使用戶可自行除權。通過以後將提案Phabricator。--J.Wong 2017年6月24日 (六) 20:55 (UTC)
- 建議設計好申請頁面後一次通過所有章程。--Temp3600(留言) 2017年6月25日 (日) 12:02 (UTC)
- 如果再過一段時間沒收到反對意見,就會着手設計申請頁面。另外,刪去首句,該句實為多餘而與後面條文相矛盾。--J.Wong 2017年6月28日 (三) 05:57 (UTC)
- (+)支持--B dash(留言) 2017年7月2日 (日) 07:57 (UTC)
- (+)支持達到一定編輯數且編輯善意、確實有需求的用戶使用機械人,但需經過嚴格審核。--Leiem(留言) 2017年7月7日 (五) 02:23 (UTC)
- 多日未見異議,故草擬申請頁,請諸位過目。--J.Wong 2017年7月7日 (五) 08:07 (UTC)
- (+)支持,寫得不錯。--Temp3600(留言) 2017年7月8日 (六) 16:41 (UTC)
- Stang 2017年7月13日 (四) 11:18 (UTC) 個人建議,申請頁部分合併至權限申請頁或BRFA。另對以上頁面進行了微調。--
- Stang君,兩者流程不盡相同,所以不建議合併,以免產生誤會。--J.Wong 2017年7月13日 (四) 16:38 (UTC)
- 這以後會變成「Wikipedia:權限申請/申請機器用戶權」,還是不屬於權限申請的範圍?--A2093064#Talk 2017年7月13日 (四) 23:22 (UTC)
- 「WP:機器用戶/申請」?--J.Wong 2017年7月14日 (五) 03:48 (UTC)
- (+)支持,寫得不錯。--Temp3600(留言) 2017年7月8日 (六) 16:41 (UTC)
- 現公示七日,屆七月廿二日。此前如無異議,則視為通過。--J.Wong 2017年7月15日 (六) 05:14 (UTC)
- (+)支持 Bluedeck 劉曉波 2017年7月19日 (三) 20:18 (UTC)
- 本案通過,已提案要求容許用戶自行移除機器用戶權限。--J.Wong 2017年7月22日 (六) 11:44 (UTC)
- 等等,機器用戶沒有自動巡查權限,應該禁止或限制機器用戶批量創建頁面,或加上自動巡查權限。--WAN233 (留言) 2017年7月23日 (日) 09:18 (UTC)
- 批量創建頁面前需經討論。例如AWB申請,而且一般用戶也用不到機器用戶權限。--Zest 2017年7月23日 (日) 13:05 (UTC)
- 要使用機器用戶權限,一般是用以執行半自動或全自動操作。如此,就需要符《機械人方針》第二段規定。該段規定,批次創建條目需要事先獲得共識。若然已經獲得共識支持,同時授予自動巡查亦非難事。--J.Wong 2017年7月23日 (日) 18:11 (UTC)
- 批量創建頁面前需經討論。例如AWB申請,而且一般用戶也用不到機器用戶權限。--Zest 2017年7月23日 (日) 13:05 (UTC)
- Phabricator已按上述申請修改代碼,現機器用戶權持有者已可自行除去權限。--J.Wong 2017年7月24日 (一) 14:09 (UTC)
大量修訂版本刪除(RRD)導致洗版,但是開啟FLOOD處理大量RRD,卻又導致RRD的處理繞過所有監察,但是如果公開請求RRD,又導致史翠珊的三角無解問題
[編輯]祝大家返校開心!那麼,最近出現了這麼一件獨特的情況,顯示出目前方針的不足,我希望借這個討論,修補這個方針問題。
管理員接收到了一個用戶的大量RRD請求,可能有幾百個,這些請求直接放在管理員討論頁上,可能是怕史翠珊再世。這幾百個RRD管理員在處理的時候,就洗版了最近更改。被巡查的用戶抗議之後,管理員就開了FLOOD,避免洗版。但是FLOOD又說必須是有共識的操作才能FLOOD,RRD請求由於出現在管理員討論頁上,顯然不能說是有共識的執行結果。又沒有共識,又開FLOOD,就造成這些請求完全躲過所有社區監察功能,顯然也有問題。然而,如果為了共識把RRD放在公開版面上,又造成了史翠珊問題。
這樣一來,問題顯示出來:凡是大量RRD的情況下,以下三個問題無法得到同時解決:1)沖刷最近更改,2)史翠珊,3)社區監察失效。
為了緩解此問題,我希望能夠在FLOOD中為RRD開一個例外:如果有大量私下RRD的情況,允許開FLOOD,但是必須在FLOOD+RRD之後,把RRD請求複製到WP:RRD頁面上做個記錄,這樣我認為就解決了上述這個三角問題。此為拋磚引玉,請大家給個看法,謝謝! Bluedeck 2021年8月23日 (一) 11:03 (UTC)
- (!)意見:「把RRD請求複製到WP:RRD頁面上做個記錄」,操作上有點複雜。--蟲蟲飛♡♡→♡℃※留言 2021年8月23日 (一) 11:20 (UTC)
- 不就是在WP:RRD上面新開一個二級標題,把用戶放在管理員討論頁上的請求複製過去,然後標記完成就可以了,不一定要按照RRD的標準模版痛苦的填寫每一個版本號碼。Bluedeck 2021年8月23日 (一) 11:26 (UTC)
- 管理人員是經信任案產生的、已被社群多數成員信任的用戶,本身便是共識的結果。如此所言,這類用戶使用flood權限理應不需要更多的信任。我們信任某用戶,將權力交予他,就應該相信這位用戶能夠判斷出
這些請求
夠不夠合理,而不是去擔心他故意使用權限以躲過社群監督(實際上開了flood也不是完全看不到)。前段時間有一個涉及封禁的討論我是這樣說的,換成RRD也一樣。社群可以監督,但那應該在最後,管理人員已經是共識下的可信用戶,這意味着他們無需事事等待事前共識,否則只是在浪費社群精力和不必要地拖時間。有人有疑慮就去單獨問行事人吧,我相信這些可信用戶能夠很好地解釋自己的行為。朝着管理人員做什麼都需要「事先共識」的方向發展可不好。回到問題上,一、用flood,管理員開flood也不需要報備;二三、不要吝嗇信任。--安憶Talk 2021年8月23日 (一) 12:07 (UTC) +2- 哦對,藍桌說的
到RRD頁面上做個記錄
是可行的。除此之外,我覺得在日誌里寫原因甚至等有心人來上門問也不是不行。還有就是,知之為知之,不知為不知。--安憶Talk 2021年8月23日 (一) 12:17 (UTC)要技術帝搞個小工具--Wiki emoji | 😷🅔🅜🅞🅙🅘🅦🅘🅚🅘😷 祝百毒不侵~ 2021年8月24日 (二) 00:04 (UTC)- 手動貼個討論頁固定連結即可,不過我不推薦這樣,因為可信用戶知道自己在做什麼。並且RRD有的時候像是淡化的OS,如無必要,不需示眾,導致該隱藏的信息反而被擴散。--安憶Talk 2021年8月24日 (二) 02:23 (UTC)
- 正是,尤其是此LTA的用戶名和編輯有引導社群輿論的意思,不知情的會被其誤導(因為此LTA破壞的頁面太多了,歷史裏還殘留着一堆有引導社群輿論的用戶名和編輯),另外我說啊,如果不想再發生這種情況,除非您們叫那個LTA不再用這些用戶名開賬號和不再做這些編輯吧[開玩笑的]。--MCC214(Sign | Contributions) 2021年8月24日 (二) 12:28 (UTC)
- 手動貼個討論頁固定連結即可,不過我不推薦這樣,因為可信用戶知道自己在做什麼。並且RRD有的時候像是淡化的OS,如無必要,不需示眾,導致該隱藏的信息反而被擴散。--安憶Talk 2021年8月24日 (二) 02:23 (UTC)
- 哦對,藍桌說的
- 去RRD上留言未免太麻煩些......話說這標題也太長了-- Sunny00217 2021年8月23日 (一) 15:49 (UTC)
- 該問題實際上是個佯謬。
- 第一,機器用戶方針並未述及「必須是有共識的操作才能FLOOD」,而僅僅是要求相關任務「重複性」和「無爭議」:「管理員在進行大量重複性、無爭議的編輯時,可以臨時授予自己機器用戶權限」、「管理員在進行重複性工作時應當使用此權限以避免沖刷掉最近更改中其它維基人的編輯和操作,但這種重複性工作必須是無爭議的」、「管理員不得使用此權限作具爭議性或不由社群允許的編輯」。
- 第二,若援引管理員方針對管理操作「唯能執行社群共識」的條文來補充論述,實質上此「共識」也不必然等同於「討論得出的共識」,如共識方針所述,「在維基百科,共識是一種典型但往往含蓄無形的過程。所有沒有異議或不被其他編者回退的編輯,均可假定其具備共識」。如果管理員正確地預判到一項批量作業有益無害(特別地,不會引起爭議),動用FLOOD權限去執行它,按照以上論述,其仍然是在執行「共識」(只不過這共識的級別相對低而已)。「RRD請求由於出現在管理員討論頁上,顯然不能說是有共識的執行結果」的說法也未必能成立。--Antigng(留言) 2021年8月26日 (四) 12:48 (UTC)