コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

Wikipedia:井戸端/subj/JST化について

JST化について

[編集]

ウィキペディア日本語版のJST化を提案します。

/別紙をご覧のうえ、ご意見をお願いします。--氷鷺会話2013年4月7日 (日) 14:08 (UTC)[返信]

コメント・賛否

[編集]
  • 管理者権限を持つ者としてではなく、あくまで個人の意見として申し上げておけば、JSTの使用は「Wikipedia:日本中心にならないように (WP:JPOV)」の精神に反することにほかならないと考えます。WP:JPOVで明文化されているのは文章の中身についてですが、その背景にある精神は、「Wikipedia:日本中心にならないように#概要 ウィキペディア日本語版は、理念としては日本語で提供される百科事典であって、「日本人だけに提供される百科事典」でも「日本の事物だけを本来の対象とする百科事典」でもないと言うことを認識することは重要です。」というところにあります。個人的意見としては、現状で行なわれている運営に関わる部分におけるJSTの適用(氷鷺さんが「すでにjawpはJSTで動いている」として指摘されている運用)も、本来はこの規定の精神に反するものであり、むしろUTCに統合されるべきであると考えています(もちろん、現状でそのような提案をしても合意は得られないという状況認識ももっていますが)。--山田晴通会話2013年4月9日 (火) 03:51 (UTC)[返信]
    • コメント まずは、Wikipedia:日本中心にならないようにを正しくそして素直に理解してください。そこには、最初から最後まで記事のことしか示されていません。Category:記事内容のルールというカテゴリ名が示している通りです。どこにもありもしない「規定の精神」を適用しないでください。確かにWikipedia:日本中心にならないようにを勝手に拡大させてしまう風潮(というか利用者)は存在しますが、それもまた日本的であり、日本中心的であり、非中立的です。JPOV!JPOV!とシステム上の運用までJPOVを持ち込むことこそ、JPOVです。日本語版はただの「日本語版」であって、決して「日本向け」ではないのと同じように、決して日本を排除した「日本以外向け」でもないのです。単に日本語話者の地理的分布を考えると、日本を含む東アジア、そして東南アジアやオーストラリアなどに偏っているためJSTが適切というだけの話です。--氷鷺会話2013年4月9日 (火) 11:22 (UTC)[返信]
  • 賛成 「基本的にはJST、ただし個人的にUTC設定可」ということで、日本語話者にとっての利便性に資することに対する特段のデメリットを見出せませんので、賛成いたします。WP:JPOVについての懸念は理解できますが、竹島 (島根県)をリアンクール岩礁に改名すべきという趣旨の指摘と同様に思えてなりません。--もかめーる会話2013年4月9日 (火) 05:26 (UTC)[返信]
  • 反対 基本的にどちらかにしなければならない理由はないと思います。個人的には、ウィキペディアがウィキメディア財団が世界的に展開している多言語プロジェクトであるということを実感する上で、時間の表示が日本のものと違うというのは、ちょうどいい仕掛けだと思っています。ある程度ウィキペディアに参加していれば、そのことを理解していることは大事だと思います。しかし、日本語と日本という国とJSTというのが、ほぼ一対一に対応しているからこそ、乗り越えるのが難しくない障壁がないと、気付くきっかけが得られない。
普通に記事を読んだり編集したりしている分には、JSTにすることで得られる利便性はそれほど大きいものとは思えません。多少戸惑うとしても、個人設定で変えることができて、それをしていないならUTCなのだと、履歴ページで案内されるようになってからは、井戸端ほかでも不満の声は見られなくなりました。その戸惑い自体をなくす必要はなく、むしろその戸惑いによる気付きが大事なのだと考えます。英語版からの翻訳については、UTCのほうが便利でしょう。ドイツ語版からの翻訳者はそれほど多くなく、英語版からUTCと書かずに翻訳したりということのほうが、数的には多くなるんじゃないでしょか。削除依頼に顔を出したり、履歴を精査したり、管理者として対処したりという人たちは、十分UTCに慣れていることが期待できます。
一部でjawpがJSTで動いていることについては、実運用としてJSTのほうが便利な部分ではJSTが採用されればいいでしょうし、混乱も生じていないのですから、現状維持がよいと思います。--Ks aka 98会話2013年4月9日 (火) 06:24 (UTC)[返信]
コメント英語版からの翻訳については、UTCのほうが便利』ということはないと思いますが、どういう意味でしょうか。jawpがUTCであれJSTであれ、英語版からの翻訳には何の影響もありませんよね。--氷鷺会話2013年4月9日 (火) 13:53 (UTC)[返信]
コメント - UTCが標準だという誤解を解消にある「英語版やドイツ語版のそれに (JST) と記入してしまうことになる恐れ」やUTC→JST変換の手間を指しているのでは?(翻訳事例は英語版(UTC)からの方が多い=頻度としてはUTC→UTCが最も多い)--ButuCC+Mtp 2013年4月9日 (火) 16:58 (UTC)[返信]
コメント うーん、だとしたら誤解ですね…。現在も、仮にJST化した後でも、翻訳時に時刻の換算は不要です。現在、翻訳時の要約欄がUTC強制でないように、JST化したからといってJSTでの記入が強制されるわけではありません。それに、現在「UTCが標準」という誤解でdeやfrからの翻訳に (UTC) と記入する例があるのと同じ頻度で、enからの翻訳に (JST) と記入してしまう例が発生する訳ではありません。後者は、JST化後の参加者で、翻訳のガイドラインや他の翻訳者のやり方も目にする機会が無く、JSTという3文字の意味を理解しておらず、しかしそれが「何か必要な魔法の言葉」だと盲目的に思い込みでもしない限り発生しないので、確率的にはだいぶ低くなります。--氷鷺会話2013年4月9日 (火) 17:25 (UTC)[返信]
確率的にはだいぶ低くなります」とのことですが、既定がJSTになり英語版など他言語版も同じJSTだと勘違いする確率が、現在のように既定がUTCでドイツ語版などCET/CESTの他言語版も同じUTCだと勘違いする確率より低くなる、というお話は首肯できません。仮に同じ確率だとして、JST化すればドイツ語版のようなCET/CESTの言語版に加えて英語版をはじめ数多くのUTCの言語版や共通プロジェクトが増えるのですから、間違う確率が同じでも絶対量がまったく違います。日本語版Wikipediaの翻訳記事の大多数が英語版Wikipediaからの翻訳であることを見ても、現在より問題が拡大するおそれはあっても逆に小さくなるとは思えないです。--Penn Station (talk) 2013年4月11日 (木) 15:30 (UTC)[返信]
  • コメント WP:JPOVには閲覧機能に関するものへの適用に限界があるということを以前、私は学びました。だから、たぶん今回の件もそういう領域にあるとは思うのですが、私はどうしても閲覧効率を追い求める気にはなれません。それは、Ks aka 98氏がおっしゃる「UTC否定の理由にならない」と匿名掲示板で見つけてきた「コモンズとの不一致」など、簡単に言うと「もう使い慣れてしまっている」「他言語版もUTCで統一したらいいじゃないか?」です。
この件でもし変更となった場合の影響範囲は、編集文章内の自動署名のみのはずです。投稿履歴や変更履歴などのシステム上の日時は個人設定によってJST・UTCのどちらも選択が可能です。その自動署名ですが、私事でお伝えするのも何ですけど、稼働中のBotスクリプトの中に自動署名をUTCで見ているものがいくつかあるので、ちょっと気にやんでます。せっかく調査集計をしてくださった提案者には申し訳ないですが、今、私は思う・・・わざわざいまさら・・・--Triglav会話2013年4月9日 (火) 12:53 (UTC)[返信]
  • 反対 JSTにすることにとり大多数の利用者にメリットをもたらす、JSTにしていけない理由はないというご説明は理解しました。しかし、私もKs aka 98さんの発言に同感です。多少の時間換算の障壁があることで、世界に開かれたプロジェクトに参加していると気づくきっかけになると思います。現状維持がよいでしょう。--Wolf359borg会話2013年4月9日 (火) 13:09 (UTC)[返信]
  • (賛成)至極当然のご提案でございましょう。絶えず9時間遅れている時計など、絶えず正確に遅れていても日本語版の時計ではございません。「原子時計というものがそもそもイカサマで、1日が永遠普遍の長さと考えてよいのは小学生まで、地球の自転に基づくGMTこそが人間の時間といえるのであり、原子時計は排除すべきだ」などの考えが便宜という観点からは全くの暴論であるように、「JSTを使えば日本向けになる」「UTCで世界に開かれたプロジェクトに参加していることの気づきになる」との精神論も「時計というものの存在価値」という観点からはいかがなものかと。また、「もう使い慣れてしまっている」は古いユーザ様の感覚でしかありません。これら感想以外では「稼働中のBotスクリプトの中に自動署名をUTCで見ているもの」だけが主な問題点でございましょう。ともかくも、UTCが何かを知らない人の数が人類では圧倒的多数でございます。--HASIDATE会話2013年4月9日 (火) 13:24 (UTC)[返信]
反対 日本語版WikipediaはWikimediaプロジェクトの数あるプロジェクトの中の一つです。全インターネット人口の73%以上(14億4200万人以上、うち日本語話者9,900万人)の利用言語(英語、中国語、スペイン語、日本語、ポルトガル語、アラビア語、ロシア語など)[インターネットにおける言語の使用参照]の言語版では既定タイムゾーンとしてUTCを採用しています。また共通プロジェクトであるWikimedia CommonsWikidataMeta-Wikiの既定は全てUTCです。日本語版Wikipediaの既定をJSTにすると、UTCの他プロジェクトとやり取りする際にタイムゾーンの違いを気にしなければならなくなるなど、相互利用や連携、交流の際の不便さが増してしまいます(相互運用性が低下します)。例えば、日本語版Wikipediaではドイツ語版やフランス語版の日時を参照する際、CET/CESTとUTCを間違われる利用者が時々おられますが、日本語版Wikipediaの既定がJSTになると、今度は英語版やスペイン語版を参照する際にJSTと勘違いする可能性がそれに加わる可能性が高いです。さらに、他言語版利用者(特にUTCの言語版利用者)が日本語版Wikipediaを参照する際にも同様のことが起こるでしょう。CommonsやWikidataを利用する際も新たな混乱を生じる可能性があります。JST化の利点はよく理解できるのですが、同時にこれら欠点もあります。現状大きな問題が起こっているとも思われず、多言語サポートが前提のプロジェクト群の中にあって、他プロジェクトを利用しやすいと同時に他プロジェクトの利用者に対してもよりオープンであるUTCの方が、既定としては望ましいと思います。--Penn Station (talk) 2013年4月9日 (火) 18:58 (UTC) 追記・微修正:Penn Station (talk) 2013年4月10日 (水) 03:08 (UTC)[返信]
コメントUTCの他プロジェクトとやり取りする際にタイムゾーンの違いを気にしなければならなくなる』根拠を教えていただけますか。それこそ、「UTCでなければならない」という実在しないルールに縛られているのであって、実際にはそんな不都合は生じませんよね。他言語版からの翻訳にしても、「何も知らない方」はそもそも要約欄記入すらできませんし、ガイドラインを読んで理解するか、他者の翻訳投稿を参考に真似るでもなければタイムゾーンを記入するに至りませんので、他言語版をJSTと勘違いして何かトラブルを起こすような事例も可能性レベルの話です。--氷鷺会話2013年4月10日 (水) 11:59 (UTC)[返信]
コメント 多分言いたいのは、ドイツ語版→日本語版の翻訳時のタイムスタンプで間違える人がいるというのと同じように、例えば日本語版→英語版への翻訳時に日本語版の活動がない日本語話者などの場合履歴の日時をUTCと勘違いする人がいるのでは?ということではないでしょうか?--Vigorous actionTalk/History2013年4月10日 (水) 14:09 (UTC)[返信]
コメント実際にはそんな不都合は生じませんよね」と断言されていますが、そもそも不都合がなければ反対していません。UTCの他プロジェクトとやり取りする際にタイムゾーン(以下TZと略します)の違いを気にしなければならなくなるというのは、TZが異なればサイトを跨がって時刻を扱う全ての作業や判断はそれを考慮に入れなければならないという、当たり前のことです。例えば、日本語版と英語版の両方に同じような内容で投稿された記事があった場合、どちらが先に投稿されたかを比較・確認する際は、それらの記事の履歴を確認するでしょう。TZの違いを認識していなければ、誤った判断がなされかねません。また、ご指摘の翻訳の際の要約欄記入で誤る場合もあるでしょう。これまでも実際にCET/CESTから翻訳する際に間違って記述する人がいるのですから、既定がJSTになればUTCからの翻訳の場合も同様の問題が生じると考えるのは必然ではないでしょうか。既定がJSTになれば、他のプロジェクトも同じJSTだと考える利用者が出てくるのは想像に難くありません。逆のパターン、つまり日本語版Wikipedia→既定がUTCの他プロジェクトの場合も同様です。現在のようにお互いにUTCであれば、どちらのサイドのプロジェクトでも問題は生じませんし、比較時に変換する必要もありません。--Penn Station (talk) 2013年4月10日 (水) 18:43 (UTC)[返信]
コメント基本的には中立的な立場なのですが、一言。JST、UTCだともめるのなら過去にある利用者が会話ページに書かれていましたがウィキペディア時間(またはjawp時間)だと考えればいいと思います。その時間をUTC運用しようとUTC+9で運用しようとUTC-5で運用しようとそれは合意形成によって決められるものならそれはそれで構わないように思います。絶対9時間ずれている時計という話をされている方がおられましたが、私は国際条約および日本国法令に基づき一日に一回以上正確に合わせなければならないUTC(国際条約上推奨)若しくはJST(日本国内でのみ許容)で表示される時計というものを設置する義務を負っています。よって絶えず正確に遅れていてもおかしいという理論には素直にうなずけません。なお私の場合はWMFの全プロジェクトでUTC設定にしてあるのであまりローカル設定の時間を気にしたことがないですし、記述時にも(Z)と略することもできるので個人的にはUTCを使うかと思います。まあ危惧するのは上で書いたように「例えば日本語版→英語版への翻訳時に日本語版の活動がない日本語話者などの場合履歴の日時をUTCと勘違いする人がいるのでは?」というのと日本時間であると表示する人がJTCと書く人が一時期増えるんじゃないかと。--Vigorous actionTalk/History2013年4月10日 (水) 14:09 (UTC)[返信]
コメント どちらかと言えば賛成よりです。ただ、メリット・デメリットを見極めたい部分もありますので、色んな立場からの資料が出て欲しいと思います。これを見て思ったのは、某新聞のJSTとUTCを取り違えた事による誤報騒動です。日本時間表示であれば問題がなかったと思う反面、間違える方が問題であるとする考えもあり、もう少しUTCであることが分かりやすくしていれば良かったのではと、色んな解釈があると思います。ただ、最近の更新を見ていて「未設定の場合はUTC」とする文章があります。もう少し分かりやすく表現する(色つけや文字サイズの拡大など)改善もありなのではと思いました。また、ラジオボタンなどによる「日本時間」「世界標準時」の即時切り替え機能がついていたら楽だなと思うことがあります。デフォルトの表示時間帯を変えなくても、表示方法を分かりやすく見直すだけでも問題は減るのではと思います。それと「JST化について」ですが、本当に分かって欲しい人には分かってもらえないように思います。つまりは「JST」が「日本時間」を意味することを理解できずに、今回の議論が理解してもらえない可能性もあります。議論名が寿限無になりますが「表示を世界標準時(UTC)から日本標準時(JST)にする提案」にした方が、分かりやすいように思えます。無理にとは言いませんが。--Taisyo会話2013年4月10日 (水) 14:34 (UTC)[返信]
某新聞の誤報騒動というのは2008年11月の件ですね。これがきっかけとなり履歴や差分ページなどで「日時は個人設定で未設定ならUTC」と表示するようにしたと記憶しています。それ以降少なくとも大手報道機関やメディアによる同様の問題は起きていないと思いますが、この変更が功を奏した、あるいは、この件が一つのきっかけとなり日本語版Wikipediaの時刻はUTCという認識が関係者に浸透した、と考えられるのではないでしょうか。JST化するとまた混乱を生むおそれがあると思います。--Penn Station (talk) 2013年4月11日 (木) 14:47 (UTC)[返信]
そのとおりです。こちらのニュースですね。UTC表示による混乱がはっきりとした形で起きた例だと思います。まあ、Wikipediaがログインしてない状態ではUTC表示であることが定着しているか否か。明確な資料がないだけに何とも言えないです。個人的には日本時間設定にしてますが、たまに設定を変更したくないけどUTC表示で見たいことがあります。これまでログイン利用者のみ設定できたタイムゾーンの変更を、「最近の更新」ページにIPユーザーでも使える形にしておく様に、プルダウンメニューを設置するだけでも今回の提案の半分程度は満たせると思います。後は、「日時は個人設定で未設定ならUTC」を設定を読み込むことで「現在表示の時刻は世界標準時(UTC)です。日本時間(JST)は+9時間してください」と表示を変えるとか、プルダウンメニューを追加したときは「現在表示の時刻は日本標準時(JST)です。世界標準時(UTC)は-9時間してください」と、現在の年月日が表示される横に大きめに表示するだけでも良くなるのではと思います。--Taisyo会話2013年4月11日 (木) 22:50 (UTC)[返信]
  • 反対 全世界の言語版がUTCいわゆる「協定世界時(世界標準時)」を用い、百科事典としての統一性を確保するのがプロジェクトの理念上、望ましいと考えられるため。ラリー・サンガーは次のように言ってます
ウィキペディアの目的は、信頼されるフリーな百科事典を――それも、質も量も史上最大の百科事典を創り上げることです。
歴史上、各地域の統治者は、各地域に統一の時刻を用いて人々に信頼を得るのが古代からの習わしですが、世界がつながって久しい昨今ではもはや地域時間を用いることは信頼を引き下げてしまいかねません。あちらの言語地域ではどの標準時間を用いているかを気にすること事体が信頼性を下げてしまいます。そして、ウィキペディアが世界標準であることは精神論ではなく、ウィキペディアの設立理念と解釈するべき重要事項だと考えています。--べあぱーく(Bearpark)会話2013年4月10日 (水) 14:55 (UTC)[返信]
UTCはただの協定世界時(Coordinated universal time)でございます。TAIをGMTと時間の表示がさほど狂わないように話し合いで精度を調整したものに過ぎません。「ウィキペディアが世界標準であること」と解釈するべき重要事項たる協定世界時の精度は、実は各国でまちまちでございます。であるならば、「ウィキペディアの設立理念とやらも、各国でまちまちなものとなる」。しかし、このような議論はどちらもこじ付け論でございまして、具体的根拠に乏しくとうてい決定の材料になるとは思えません。--HASIDATE会話2013年4月10日 (水) 16:51 (UTC)[返信]
  • コメント まがりなりにも10年以上運用されてきたものを変えようというご提案なのですから、利便性というだけでは弱いかと思います。変更すべきと思われる納得できる理由を示して欲しいです。すでにjawpはJSTで動いているJSTにしてはいけない理由はない、という主張は拝見いたしました。では、UTCではだめでJSTにしないといけない理由はあるでしょうか。私には思いつきません。
    • 唯一積極的な理由として日本語話者にとっての利便性をあげていらっしゃいます。しかし、それはシステム時間設定を変えないと解決できないものなのかどうか。UTCのままが良い利用者に対し個人設定で対応できると主張されるなら、現状でも個人設定でJST(アジア/Tokyo)表示に設定できるわけです。ガジェットの新設まで考えているなら、たとえば初心者にもわかりやすいインターフェースの改良まで考えてもよろしいかと思います。
    • JSTにしてはいけない理由はない論拠として他言語版のプロジェクトの状況の表を示していらっしゃいますが、これでわかるのは全世界のプロジェクトがUTCに統一されているわけではない、ということだけです。私は表を見て「利用者のローカル時間とシステム時間が一致してる例って全体のどれくらいなんだろう?」と素直に思いました。
    • すでに稼働中のBotスクリプトで影響が出るものがあるとの指摘があります。確実にリスクや痛みはあるわけですが、過小評価していないでしょうか。そして、それを上回る必要性があるでしょうか。
    • 「絶えず9時間遅れている時計」、「日本語版の時計」と指摘されている方がいらっしゃいますが、では「英語版の時計」はどうあるべきしょう。
    • Ks aka 98さんのおっしゃった「日本語と日本という国とJSTというのが、ほぼ一対一に対応しているからこそ、乗り越えるのが難しくない障壁がないと、気付くきっかけが得られない」ですが、これはまさにその通りだと思うのです。決して無意味な精神論などではありません。なお、WP:JPOVが取り上げられていますが、これはまだ提案中の文書です。これに書いてある/書いてないで論ずるのは不適切かと思われます。
    • 他のプロジェクトとのやりとりでの要約欄の問題ですが、これはUTCだろうとJSTだろうと同じことです。ただ、一時的にせよUTCからJSTに変えることによりミスが増えるのは間違いないでしょう。そもそも、UTCやJSTの意味を解さない方が他言語版からの翻訳を行うこと自体が問題です。
    • この場は「ウィキペディア日本語版のシステム時間設定をJSTに変えたい」というご提案を検討しているものと認識しております。ですが、ただUTCを批判したいだけの方がおられるようです。--Wolf359borg会話2013年4月10日 (水) 22:50 (UTC)[返信]
(コメント)ハワイからグアムまで長大な時間帯をもつ英語圏と北海道から沖縄までの日本語圏を比べる点ですでにいかがなものかと…。UTCではだめでJSTにしないといけない理由はただひとつ、NICTの日本標準時は1秒の精度が世界一であるからです。上記論者の最大の勘違いはUTCを中継しているのがJSTであると考えてられる点でございまして、JSTはNICTが作る日本製の「時間」でございます。--HASIDATE会話2013年4月11日 (木) 12:44 (UTC)[返信]
念の為にお尋ねしますが、表記をJST化したとしても「NICTの日本標準時は1秒の精度が世界一」という恩恵を得ることが出来ないことは、ご理解されている上での発言でしょうか。仮にその上で上記のようなご発言をされてるということは、UTC+9:00であるJSTという単語そのものにご理解が得られていないものと思われますが、いかがでしょうか。--Frozen-mikan会話2013年4月11日 (木) 13:03 (UTC)[返信]
(コメント)精度は無関係ですので、この話に関係のない話を持ち出して混乱させるようなことは控えていただけると助かります。繰り返しますが、精度もNICTも関係ありませんし、それはここに出てくる筈のない言葉です。--氷鷺会話2013年4月11日 (木) 13:17 (UTC)[返信]
(コメント)JSTもUTCも作られたものであり、自然に存在するものではございません。UTC+9:00であるJSTであるなら、KSTでもUTC+9:00で同じでございまして便宜上はJSTの必要性などどこにも存在いたしません。KSTを日本語版で使用すれば、日韓で統一ができてよろしいでしょう。しかし、JSTとKSTを分ける理由は同じに見えても、実はどちらも別の時計の示す別の時間であるからでございます。すなわち日本の社会も鉄道もテレビもNICTの作るJSTで実は動いているのでございます。そして、我々が恩恵を得ることが出来ないのではなく、既に恩恵を被っているのでございまして、それがJSTにする唯一の理由ということでございましょう。会社の書類や電子カルテなどがJSTで作られており、ウィキペディアが閉じられた場所ならともかく、情報通信技術の要たる時間の正確性は、日本社会の共通の親時計の精度の上にのみなりたち、正確性ゆえにそれが用いられるのでございます。単語の意味は文脈で変化するものでございます。すなわち日本社会はJSTで活動している。JSTがICTで使用される理由は便宜性のみならず、その精確性による。以上でお答えになっていますでしょうか?--HASIDATE会話2013年4月11日 (木) 14:53 (UTC)[返信]
(コメント)どちらの疑問にも率直にお答えいただけなかった点、非常に残念に思います。ではありますが、前者の疑問については、以前と同様の主張されていることから、問題の趣旨を全く理解されていないことを確認できました。ありがとうございます。氷鷺さんもコメントされていますが、これ以上、無理解を装う発言を重ね、他者の無知につけこむことは控えられた方が良いかと思います。--Frozen-mikan会話2013年4月11日 (木) 15:30 (UTC)[返信]
コメント お願いしますから、もうやめてください。あなたが仰るような話はしていないのです。そういうJSTはこの話と無関係ですし、正確性正確性と言うのなら世界中の(NICTやNIMJを含む)周波数標準器に基づくUTCのほうが正確性では上でしょう。そもそもそういう話はしていないので、もうおやめください。--氷鷺会話2013年4月11日 (木) 15:41 (UTC)[返信]
  • コメント たとえば私や、よく名前を見かける、現段階で既に何年か経っているような方には基本的に必要性はない提案ではあります。我々ウィキペディア中毒には「今更」でしかありませんが、否定する理由にしてもその「今更感」、慣れ、感覚、精神論に止まるのが現状です。ミスが生じる、というのも「なんとなく」の想像しかまだ語られていませんし、それにしてもそのミスは致命的ではなく現在でも見逃されている程度のものです。今のところ、「JSTにしなければならない」理由がないのと同レベルで、「UTCのままでいなければならない」理由も、誰一人挙げられていません。--氷鷺会話2013年4月11日 (木) 13:17 (UTC)[返信]
Wolf359borgさんも仰っていますが、UTCには過去10年間の実績があり、また途中起こった問題にも対処・改善したこと(上記 2013年4月10日 (水) 14:34 (UTC) のTaisyoさんへのコメントで触れました)により、現在では大きな問題なく運用されていています。JSTでもUTCでもいずれにせよ一長一短あるのはこれまでの議論でも示されてきました。そうであるのなら、デメリットを上回るメリットが示されない限り、現状維持とするのが合理的だと思います。まぁそのデメリット・メリットの捉え方が違うのでしょう…。この状況下で敢えてリスクを冒してJST化するより、(プロジェクトとして)他にやるべきことはたくさんあるのでは、と私は思います。--Penn Station (talk) 2013年4月11日 (木) 14:47 (UTC) 追記:Penn Station (talk) 2013年4月11日 (木) 15:30 (UTC)[返信]
  • 賛成 まず、日本居住者にとって日本時間表記のほうが利用しやすいことは確かです。ウィキペディア日本語版を読む人間は、コミュニティで活発に活動している利用者の何倍もいるはずですから、その方たちにとっての利用しやすさを考えれば、日本時間にすることは合理的な対応でしょう。もうひとつ、これは私がウィキペディアや translatewiki などで活動して常々感じていることですが、ウィキメディアプロジェクトはローカライズに対して非常に気を配ったプロジェクトです。多様な言語で情報を提供することや、多様な言語にあわせてサイトの UI をローカライズすることに大変熱心です。各言語の文法における性別を考慮して UI を変えるなど、私は他の大きなサイトでは例を知りません。各プロジェクトごとにタイムゾーンを変えられるようにしているのもそのあらわれでしょう。私はこの国際化と地域化に関する考え方がウィキメディアプロジェクトの特徴の一つだと思っています。日本語版が日本時間を採用することになったら、他の言語版も同じようにそれぞれの時間を使っているのだということを意識しながら、多文化のプロジェクトとして協調していけるものと思います。--fryed-peach [会話] 2013年4月12日 (金) 00:56 (UTC)[返信]
  • コメント主従関係が明確」発言の次は「システムの時間設定をJSTにする」発言ですか。著作権だけでなくコンピューター関係も氷鷺さんで何か提案するのは無理ですね。技術的側面を無視して考えたり別紙を用意したり議論しても無駄です。非常に根本的に誤解なさっているようですが、日本語版に限らずウィキペディアのシステムはUNIX系のOSで動いて、UNIXマシンのシステムクロックはUTC以外に設定できません。世界のどこに設置されていようと、Windows系のOSのようにシステムクロックを現地時間に設定したりはしません。UNIX時間を見れば分るように、これは1970年の昔からそうです。設定可能なのはタイムゾーンの方です。氷鷺さんでしたら、システムの時間もタイムゾーンも同じだろう、のような弁明をするかもしれませんが、コンピューターが解っている人間ならタイムゾーン程度は知っているので「システムの時間設定をJSTにする」のような発言は出てこないのですよ。氷鷺さんの「UTCでなければならない」という実在しないルールに縛られているのであって、実際にはそんな不都合は生じませんよねという発言は、システム運用に関わる議論をする資格を有していない証拠のような物です。
精度は無関係というのも厳密には間違いです。ファイルを別のUNIXマシンにコピーしたらタイムスタンプが狂うようではリモートバックアップも取れません。それでネットにつながっていればNetwork Time ProtocolでシステムクロックがUTCに自動的に合わせられ実用上十分な精度で同期が取れる仕組みになっています。とはいえGPS時刻程度の精度があれば十分ですが、9時間も意図的に狂わせるというのは有り得ないですね。
Gigazineの記事によれば2010年の段階でもWikipediaは大規模なシステムで動いています。自宅のPCのようなイメージで考えてもらっては困ります。そしてシステム運用者は(2010年時点では)6人しかおらず、すべき仕事がたくさんあるのに、なぜ「好みの問題に過ぎない」ような変更を強いて仕事を増やすのでしょうか。一部のサーバーのMediaWikiだけにタイムゾーンの変更を行って予想外のトラブルが生じたときに誰が苦心して原因調査して対策するのですか。「調べたがこれは直しようがない。JSTにしてくれと言ったのはjawpだろう」と言われたらどうしますか。だいたいMediaWikiだけタイムゾーンをJSTにしてもPHPもDBもUNIXマシンもUTCのままで動くでしょう。date (UNIX)を使用していて、かつ「jawpはUTC」という前提で過去10年に作成されたものはBotを含め全て修正が必要になります。
タイムゾーンをJSTにするデメリットは
  • 日本でサマータイムが導入された際にトラブルを招く。過去に幾度も提唱されていましたが最近でも政府の産業競争力会議が省エネ促進のためサマータイム導入を提言に盛り込むというニュースがあります。原発は止まっているし先は分りません。法案が通ってから「想定していなかった」では賢明とは言えません。一方、現状通りUTCならこの先サマータイムがどうなろうと関係ありません。
  • 日本語版の記事が他言語に翻訳される場合に時刻をUTCと勘違いする人が出るのを防ぐために主要各国語で「JSTになった」と案内文を用意する必要が生じます。言い出した氷鷺さんが用意しますか。
  • 他言語では以下のようなトラブルも発生しています。
これらは以前の事なので現在は直っているのかそれとも解決不可能な事柄なのかは分りませんが、今のバージョンでタイムゾーンを変えれば、別の問題が生じる程度の事は予期すべきです。
結局、氷鷺さんがメリットと力説している事柄は、JSTの方が良いと考える利用者が個人的にタイムゾーンの設定を変えれば全て実現可能なことに過ぎず、MediaWiki側のシステムのタイムゾーンを変える必要など全くありませんから、システム変更のメリットは実際には何一つありません。これは氷鷺さんにタイムゾーンの概念が無いために、意味が無いと分らないだけです。「実際にはそんな不都合は生じません」に関してもそうです。氷鷺さんがシステムのことが理解できないから不都合が生じうるという事が理解できないのに過ぎず、それは実際に変更後に不都合が生じない事を意味しません。このような提案はシステム運用ができる位の人がすべきですが、最低でも自宅のPCでLinuxとMediaWikiとPHPとMariaDBを動かして実験する程度は楽々やってのける程度の技術力も無い人がシステム運用がらみの提案をするのでは電気店で「インターネットください」と注文をするのと変わりありません。もし技術的な事が理解できないのでしたら、2000年問題の事は覚えていますか。氷鷺さんの提案は必要も無い2000年問題のような混乱を招き他者に負担を強いた挙句、仕様だから諦めてくれとシステム運用者から言われ解決できないトラブルを今後ずっと我慢して使う羽目になる恐れもある、と言っておきます。幾多のバグ修正の手間をかけ10年間動いているjawpのシステムなのに意味の無い変更をしてバグを生み出し、そのバグの修正をお願いして回るのはおかしいです。--210.253.249.79 2013年4月12日 (金) 12:15 (UTC)[返信]
  • コメント どなたでしたっけ。引用の要件が争点となる問題で、ええと、私が存続側ですか。殊著作権の話で私がそういう言い方をされるということは、そしてこれほど話の流れを無視した的外れな反論をされるような方――あなたの主張は、たしか認められていないように思われますが。
    「システムの時間設定をJSTにする」というのは、普通に解釈すれば、あなたのような話にはなりません。コンテンツである記事ではなくシステムの、という意味です。したがって、UNIX云々というのも的外れですし、基本的にあなたのご指摘は最初から最後まで一貫して的外れです。サマータイムが導入されれば自動的に適用されます。ロシアがサマータイムを廃止した(というかサマータイムを通年の標準時にした)ような現実世界での法改正による標準時変更は当然、反映されます。別にそれほど珍しいことではありません。案内文を用意しろなどという要求にも対応しません。不要でしょう。曜日が狂うとか、アップロードと削除の記録だけがUTCのままなどといった大昔のバグはもう何年前か忘れるくらい昔に修正されています。この問題について『最低でも自宅のPCでLinuxとMediaWikiとPHPとMariaDBを動かして実験する程度は楽々やってのける程度の技術力』は不要ですし、それを要求するほうが話題に付いていけていないということに他なりません。--氷鷺会話2013年4月12日 (金) 14:25 (UTC)[返信]
  • コメント(2度目)氷鷺さんは覚え切れないほど暴言を各所で繰り返しておられるようですが、言われたWiki100さんは忘れないと思いますのでお答えしますと、コメント依頼で言及したWikipedia:削除依頼/新世紀エヴァンゲリオン 20121025の件です。著作権の条文を自作するという、著作権を論じる資格無しの依頼文を書いておきながら存続側に「知識もなく依頼文を読む能力もなく軽率に判断するような真似は控えてください。まずは勉強してください。」とあべこべに暴言した件。結局、Wiki100さんに謝罪しなかったんですね。
それにしても氷鷺さんはおっしゃる事が出典ゼロですね。とにかく、Linuxを扱える技術力を有しておらず、GigazineのこれがWikipediaの裏側、知られざる大規模システムの実態「Wikipedia / MediaWiki におけるシステム運用」の記事を読んでも何も理解できない(理解していれば内容を踏まえた上で反論する筈だから)人だというのは良く分りました。要するに氷鷺さんの考えでは、ウィキペディアのシステムの変更を提案したり議論したりするのに技術的なバックグラウンドなど一切不要、ということですね。これですと、10年前は電気店で「インターネットください」と注文をするのは、現在ではシステム運用者に「JSTください」と注文すれば済むと考えているのと同じレベルです。
「コンテンツである記事ではなくシステムの、という意味です。」という発言から氷鷺さんはmw:Manual:Timezone/jaを見ても理解できないことは明らかですし、そもそも技術的な話しは無理ですので、もう他の部分に関してもいちいち議論することはしません。もし氷鷺さんにGigazineの記事を読んである程度理解できる日が来れば、話しもできるかと思いますが、その日は来ないでしょう。
「曜日が狂うとか、アップロードと削除の記録だけがUTCのままなどといった大昔のバグはもう何年前か忘れるくらい昔に修正されています。」に関してですが、これだけは、どうでも良いことではなく非常に大事なことなので確認させていただきます。ウィキペディアは出典主義ですので、バグがあったことは明らかですので、それが忘れるくらい昔に修正されていますと技術的バックグラウンドがゼロな氷鷺さんの口約束を根拠に、ハイそうですか、と進めるわけには行かないのです。バグが直っていることが第三者に分るように証拠を示していただけますか。私の方からは、そう簡単には直らない性質の問題かもしれないと思われる点に関して述べておきます。
  • mw:Manual:Timezoneには "Note: Upload and deletion logs will probably still be listed in UTC" とあって、履歴を見ると 14 February 2013 が最終更新です。単純に考えると、「今も直っていない」と思われますが、いかがでしょう。私などは、ファイルのアップロードと削除はMediaWiki側ではなくUNIXのシステムコールで処理されれば、MediaWikiをJSTにしてもUNIXはUTCで動くのだから時間がUTCで返ってくるのは仕様だとされても仕方が無いと思われます。
  • 曜日が狂うのは、DBとMediaWikiのタイムゾーンが違えば起き得ると思われます。
単純に「システム全てのタイムゾーンをJSTに統一すれば良い」のような変更が不可能である事はGigazineの記事を見れば明らかですので、あらかじめお知らせします。--210.253.249.92 2013年4月13日 (土) 15:31 (UTC)[返信]
  • コメント 個人的には「現在、世界標準時表示を標準にしているのを、日本時間表示を標準にしたい」、「書名についても同様の表記にしたい」程度で受け取っています。内部システムは世界標準時のままで、アウトプットを日本時間にすると解釈しています。そのレベルであれば、他の言語版で既に実現している。6年前にトラブルがあったけど、普通はそれだけの期間があれば、バグフィックスは十分出来ているはずです。実績のあるシステムを日本でも採用しようが今回の提案と思います。もっとも、技術的に専門的なことになると、私も無理なところはあります。ただ、「こんな事が出来たらいいな」と提案するのは問題ないと思います。その中で、システム的に出来ることを落とし込む。より技術のある人に意見をまとめて貰う。それで良いのではと思います。--Taisyo会話2013年4月14日 (日) 01:48 (UTC)[返信]
  • 反対 (誤解があれば御教示頂きたいのですが)、あちこちで「AさんはXXXX年XX月XX日 (X) XX:XX (UTC)の発言で~のように仰っていますが、私は~のように思います」のような形式で書かれているコメントをよく目にします。これもボットで修正できるんでしょうか?できないという前提で話を進めますが、ある日を境にJSTに変わると混乱しませんかね?(あれ?この発言は未来になってる、って感じで)。もう1点、UTC間違え事件のせいで大手マスコミでは「WikipediaはUTC」が定着しているはずです。他にも反対理由はありますが、既に皆様が仰ったので割愛します。--JapaneseA会話2013年4月13日 (土) 08:57 (UTC)[返信]
  • いくらかまとめて、意見を述べてみます。--Burthsceh会話2013年4月14日 (日) 10:52 (UTC)[返信]
    • 日付・時刻関連のMediaWikiの仕様等について説明します。
      • まず、ウィキ全体のタイムゾーンの設定については、通常は$wgLocaltimezone(節「Details」のNoteを除いた部分はたいてい正しいと思います。)で設定すれば切り替わります。特には$wgLocalTZoffsetを変更する必要はありません。PHPの設定 (環境変数TZとdate.timezone)、OSのタイムゾーンも変える必要はありません。mw:Manual:Timezoneは、古くてあまり役に立たないと思います。includes/DefaultSettings.php のコメントが正確だと思います。
      • 曜日がずれるバグについては、r23017 (Bug 8577) で修正されています。
      • ログ (includes/logging/LogEventsList.php) やファイルページのファイルの履歴の表 (includes/ImagePage.php) の日時については、Languageクラス のuserTimeAndDateメソッド(以前はtimeanddateメソッド。ところによっては、userTimeメソッドとuserDateメソッドが使われます。)を用いているので、グローバル変数による設定と個人設定のタイムゾーンに応じて変わります。
      • APIの出力やXML形式のデータベースダンプでは、常にタイムゾーンがUTCのISO 8601が使われるはずです。
      • 時刻の精度は、タイムゾーンの設定とは関係ありません。
    • その他
      • UTCで表記された日時のBotによる置換はできないことはないですが、かなりの数があり、置換してはならない、置換しないほうがよいものを考慮すると、大変だと思います。
      • 他言語版のページの翻訳の投稿の際の要約欄記入には、ウィキペディア日本語版のタイムゾーンは関係ありません。
      • タイムゾーンが異なる日時を比較するときには、タイムゾーンを考慮しなければなりません。タイムゾーンは、翻訳元の版の調査、他言語版との比較、スチュワードによる対処の確認、MediaWikiと拡張機能の更新の確認などにかかわります。
      • ある程度混乱・間違いは起こるだろうと思います。
    • UTCに慣れたので、反対よりですが、賛否は保留します。--Burthsceh会話2013年4月14日 (日) 10:52 (UTC)[返信]
  • コメント(3度目) Burthscehさん、正確な説明をありがとうございます。私のような素人が質問などして申し訳ありませんが、結局今回の「JST化」が行われれば、Help:個人設定#時差でタイムゾーンを設定した場合と比較して、署名の~~~~の部分が展開時に時刻がJSTになるというのが利用者側から見た利点であり、逆に、今までどおり署名をUTCにしたいという人がいてもJST以外にはできない、という理解で合っていますでしょうか。教えて頂けましたら幸いです。--210.253.249.98 2013年4月14日 (日) 12:10 (UTC)[返信]
    • 返答しようか迷いましたが、します。ほぼその認識で間違いありません。現在のMediaWikiのタイムゾーン関連の処理の流れをより詳しく説明します。$wgLocaltimezoneと$wgLocalTZoffsetはDefaultSettings.phpでnullに初期化されます。必要ならば、LocalSettings.phpで2変数の値を書き換えます。Setup.phpで、まず$wgLocaltimezoneがnullであったら、$wgLocaltiezoneにdate_default_timezone_get()から取得した値を設定し、date_default_timezone_set( $wgLocaltimezone )でdate.timezoneを設定しなおした後、$wgLocalTZoffsetがnullであったら、タイムゾーンにあわせて$wgLocalTZoffsetを設定しています。署名を置き換えるParserクラスのpstPass2メソッドは、タイムゾーンについては$wgLocaltimezoneだけ($wgLocaltimezoneは適切に設定されているはずで、そうでないとしてもdate_default_timezone_get()で取得したものを使うので。)に従います。これに対してLanguageクラスでは、$wgLocalTZoffsetと個人設定のタイムゾーンが使われます。(必要に応じてMeta Wiki、MediaWiki wiki、Subversion(viewvc)、Gerrit(gitweb)、Doxygen(doc.wikimedia.org)、PHPのマニュアルを参照したり、検索したりしてください。)--Burthsceh会話2013年4月20日 (土) 04:54 (UTC)[返信]
  • コメント 個人的にはJST化に賛成寄りではあるのですが、変更はかなり困難(事実上ほぼ不可能)だと思ってます。1つには「日本国内居住者によっての利便性」というのがうまく可視化されにくく、差し迫った必要性のある話題として(つまり他の問題と同等の優先度をもつものとして)認識されにくいことがあり、2つ目としてはjawp(に限りませんが)は「両方に一長一短がありどっちにも圧倒的賛成がないのなら、従来通りのものが採用されていく」という硬いシステム(硬性憲法的な意味での)であることがあります。もしjawpが最初からあるいは比較的初期の段階でJSTで動いていればすんなり受け入れられたことだったのでしょう。「変えたほうがいいのは分かるけど変えることのできない」案件としておくしかないのではないかなぁと思います。--青子守歌会話/履歴 2013年4月14日 (日) 13:52 (UTC)[返信]
  • コメント(4度目) 氷鷺さんが「大昔のバグはもう何年前か忘れるくらい昔に修正されています」と太鼓判を押されたのは2013年4月12日 (金)14:25 (UTC)。その点に関しては証拠を示すように私の方でお願いしましたが、氷鷺さんの代わりに Burthsceh さんが2013年4月14日 (日) 10:52 (UTC)に回答してくださいました。それを拝見した結果、氷鷺さんがおっしゃった事には良く判らない点が生じて参ります。なぜなら韓国版で曜日が狂うというバグが直っていた事を知っていたのであれば、氷鷺さんが韓国版ウィキペディアをしばしばご覧になったり投稿したりしているか、Bugzilla のBug 8577を見ていたかのどちらかしか無いように思われます。しかし氷鷺さんがハングルが得意ならkoの記事を翻訳立項することも可能で朝鮮ポータルの常連とならなければおかしいですが氷鷺さんを朝鮮ポータル見かけた記憶はありませんし、『最低でも自宅のPCでLinuxとMediaWikiとPHPとMariaDBを動かして実験する程度は楽々やってのける程度の技術力』は不要ですし、それを要求するほうが話題に付いていけていないとまで言う位に非技術系の人が Bugzilla を見て知っていたということは有り得ないですから。改めて伺いますが、氷鷺さんは2013年4月12日 (金)14:25 (UTC)のよりも前の時点でどうやって「何年前か忘れるくらい昔に修正」されていた事を知るようになったのか教えていただけますか。--210.253.249.115 2013年4月15日 (月) 14:44 (UTC)[返信]
  • このIPユーザですが、一貫して無関係の話しかしておりませんし、目的も言動も議論妨害でしかないようですので、(本人以外)反論が無ければノートに移したいと思います。--氷鷺会話2013年4月15日 (月) 16:07 (UTC)[返信]
210.253.249.xさんの発言は残しておくべきでしょう。発言内容が適切かどうかはともかく、少なくとも無関係ではないです。他に議論妨害としか思えないコメントがあったはずですがそちらは放置されるようですし。氷鷺さんは技術的な側面にはあまり関心をお持ちではないご様子ですね。--Wolf359borg会話2013年4月15日 (月) 17:11 (UTC)[返信]
このIPの発言で、この話題に関係のある意味のあるものが一つでもあったでしょうか。誤解と捏造と暴論、それ以外の情報はどこにもないというくらいに終始「間違ったことだけを言う」という特徴のあるIPユーザですけれども。上のほうでJSTやNICTの精度云々と主張されていた方はとりあえず黙っていただけたようですが、こちらは以前から「とにかく間違ったことだけを言う」行為を繰り返してきた人物ですので、相手をせず早めに対策を打っておいたほうが無難だと思います。この問題と無関係な、このIPが言うような話題には興味ありません。関係があると思われていましたら、たぶん誤解というか「騙されてしまっている」恐れがあります。しかしこの提案に必要な程度の知識は(そもそも大して必要ではないのですが)持っているかと思います。--氷鷺会話2013年4月15日 (月) 17:50 (UTC)[返信]
コメント(4度目) やはり氷鷺さんは、韓国版ウィキペディアでバグが修正されている事もBugzillaを確認する事も無しに「大昔のバグはもう何年前か忘れるくらい昔に修正されています」と、確認していない事実を既に確認しているかのように装って井戸端で説明したのですね。嘘をつくとは重大ですね。そもそも技術が分らないなら事前に Burthsceh さんあるいは他のシステム運用が分る人に教えてもらってから提案・とりまとめをしようと考えないのも氷鷺さんらしいし、内容そのものに問題点があるから意見がすんなり通らず反論を受け、それでも自分の意見を通そうとして通常と異なる手段を選ぶというのも氷鷺には良くあるパターンですが。--210.253.249.85 2013年4月18日 (木) 13:05 (UTC)[返信]
  • 反対 国がサマータイムを導入した場合に対処する案件が増えるため、サマータイム施行のおそれのない、現行のUTC使用を継続する方が適切と判断します。氷鷺さんの仰る「してはいけない理由はない」には頷けますが、同時にしなければならない理由もありませんし、わざわざ国の施策に振り回される可能性のあるJSTに移行するのを避けない理由もありません。また氷鷺さんの思考実験のためにウィキペディアの方針を変更する必要もないでしょう。--Himetv_ 2013年4月15日 (月) 19:09 (UTC)[返信]
    • コメント 擁護するわけでも無いですけど「また氷鷺さんの思考実験のため」に提案したは言い過ぎだと思います。恐らく、サマータイムの導入は当面はないとした上で、日本人の感覚の時間に合わせたい意味での提案に思います。--Taisyo会話2013年4月15日 (月) 22:33 (UTC)[返信]
    • コメント 万が一サマータイムが導入されたら現実世界がそれに「振り回される」訳ですが。現実世界の時間に振り回されない人間など(たとえニートや引きこもりですらそうそう)いないでしょうし、その反論は意味が無いのではないでしょうか…。--氷鷺会話2013年4月20日 (土) 06:03 (UTC)[返信]
コメント 予想外に#投票節が作られるなど、何やら急いて回答しなければならない状況のようなので、深く考える時間もないままですがコメントを。
JSTないしUTC+9を採用すると、いよいよもって「ここは『日本版ではなく日本語版』」というタテマエが外部に対して使用できなくなりますが(「サーバが米国にある」は残りますけど)、わざわざ「ネット選挙解禁」といったややこしい(何が起きるか分からない)時期にリスクになりうることをしなくてもよいのではないかと考えます。投票を行なうこと自体は別に賛成も反対もしませんが、やるならば日程だけ決めて半年程度先送りしたほうが良いのではないかと。--Starchild1884会話2013年4月20日 (土) 21:51 (UTC)[返信]
コメント 韓国語版ウィクショナリーが同じ論理で二ヶ月前にUTCからUTC+9(KST)に変更したそうです。(私はお話にならないと書いておきましたが。)署名は標準設定で設定で変更以前の記述はUTC、変更以後はKSTになっています。--hyolee2/H.L.LEE 2013年4月21日 (日) 07:50 (UTC)[返信]
賛成 ウィキペディアの一閲覧者としてJSTへの移行に賛成します。これまでUTCが原因となった問題は数多くあり、その中でも他の方も挙げている毎日新聞の誤報騒動については、落ち度があるはずの毎日新聞側が終始「こちらは悪くない」という姿勢であった上、JAWPコミュニティから十分なフォローが行われなかったために、落ち度がないはずの編集者が一方的に被害を受けました。今後同様のトラブルが今後発生しないとも限らず、この一例だけでも移行の動機として十分と考えます。--138.243.217.39 2013年4月26日 (金) 09:07 (UTC)[返信]
質問 「これまでUTCが原因となった問題は数多くあり」と仰いますが、具体的には何がありましたか? 毎日新聞問題は覚えていますが、他に何かあっただろうかと、思い当たる節が私にはありません。「この一例だけでも~」と仰っているので138.243.217.39氏のお考えには影響はないのだろうと思いますが、私としては多数問題があったというのであれば、それらをきちんと把握しておきたいのです。--Starchild1884会話2013年4月26日 (金) 23:01 (UTC)[返信]
コメント 閲覧者やIP利用者の利便性を考えた場合、初期状態でJST表示されること自体のメリットはほとんどの方が認めるところだろうと思います。しかし、それをどう実現するか、それにともなうリスクやデメリットはどうか、について議論が必要であるように思います。例えばですが、非ログイン状態で変更履歴を閲覧した場合にも時刻をJST表示させる手段が用意出来れば、デフォルトのタイムゾーン設定を変えなくともとりあえずの目的は達せられるわけです。なお、某新聞の誤報騒動に関しては明らかに新聞社側に問題があります。履歴表示がJST表示されていたとしても、時刻誤認は防げるかもしれませんが、メディアに注目されるような主題に関して不用意な編集を行った結果として不適切な取り上げ方をされてしまうリスクは消えるわけではありません。jaWPコミュニティのフォロー不足云々もタイムゾーンを"Asia/Tokyo"にする件とは関係ない話でしょう。--Wolf359borg会話2013年4月27日 (土) 06:56 (UTC)[返信]
  • コメント 以前の私のこちらあちらのコメントで、そのような機能の提案を既にしております。ただ、反応がなかったため受けないのかなと思い、以後の意見固めをしていませんでした。興味があるのでしたら、心当たりある技術のある利用者に、実際にそのような仕様の実装が容易かどうか、確認してみたいとは思います。--Taisyo会話2013年4月27日 (土) 14:20 (UTC)[返信]
たいへん興味があります。技術面も含め、多角的に検討がなされるべきだと思います。--Wolf359borg会話2013年4月27日 (土) 16:23 (UTC)[返信]
分かりました。とりあえず、以下の仕様で問い合わせてみたいと思います。もちろん、問い合わせした利用者以外の返答も構わないですし、別アプローチでの実現についても提案があればお願いしたいと思います。現時点では、利用者設定で行う物なので、設定の優先順位などの問題は出るのかも知れません。また、設定の追加が困難な可能性もあります。
  • 現在、『最近の更新』や『利用者の投稿記録』、『「***」の変更履歴』などのページでは、『日時は個人設定で未設定ならUTC』と表示されています。それらに、『ウォッチリスト』を加えて、時間帯表示に関して、タイムゾーン設定を読み込むことで『現在表示の時刻はUTCです』や『現在表示の時刻は日本時間です』と切り替えて表示することは、技術的に容易でしょうか。
  • 『最近の更新』や『利用者の投稿記録』、『「***」の変更履歴』、『ウォッチリスト』などのページで、ラジオボタン方式などによる、UTCとJSTの単純切り替え表示機能の追加は容易でしょうか。設定有効時間はブラウザを開いている期間のみとし、閉じたときはリセットする仕様で考えています。
  • 『最近の更新』や『利用者の投稿記録』、『「***」の変更履歴』、『ウォッチリスト』などのページで、プルダウンメニュー方式などによる、複数の時間切り替え機能の追加は容易でしょうか。設定有効時間はブラウザを開いている期間のみとし、閉じたときはリセットする仕様で考えています。
多分、それらの実装が実現するのであれば、変更するしないにかかわらず、両方にメリットがあると思います。--Taisyo会話2013年4月28日 (日) 13:02 (UTC)[返信]
先に話していた機能追加ですが、プロジェクト‐ノート:ウィキ技術部#時間表示についてBurthscehさんにより作成していただきました。改めてお礼申し上げます。ただ、機能確認のまとまった時間が取れていないので、自分の言葉で説明がまだ出来ない状態です。興味がありましたら、テストしてみればと思います。--Taisyo会話2013年5月4日 (土) 01:45 (UTC)[返信]
  • コメント(反対より)JSTに変更するメリットの説明はありましたが、UTCのままにしておくデメリットについて詳細な理由を説明されていない以上、現行のままでいいのではと思います。JST化が強行された場合、過去にあったWikipedia:井戸端/subj/名前空間名の変更への対応のとき以上の混乱が起きるのではとの危惧があるのと、LTA:DX0に対処してきた経験からすると「荒らしを大量の履歴の中に埋もれさせる餌(ここでは単なるUTC→JSTへの変更)を与えるべきではない」との判断です。--VZP10224会話2013年4月27日 (土) 06:04 (UTC)[返信]
  • コメント 自身の反対意見に追記です。最近、次のような経験をしました。他言語版より履歴不継承を理由とした削除依頼で、何とか履歴補完しようとしたのですが、記事の作成者は日本語が得意でない方(友人の方が翻訳されたそうです)でした。私が下手糞な英語で会話するしかなく、「どの版から翻訳したか?」と聞き出すのが大変でした。タイムゾーンまで異なっていて、更に面倒でした(相手の方のタイムゾーンはCETでした)。日本語版を編集する方のタイムゾーンはJSTとは限らない事を痛感しました。JSTにした日本語版からUTCである英語版やUTCでない他言語版に翻訳して、同様の問題になった際、余計ややこしい事にならないでしょうか?--JapaneseA会話2013年4月27日 (土) 07:51 (UTC)[返信]
  • 読み込み解除される前にコメントします。特定のタイムゾーンにしなければならない理由はありません。タイムゾーンの設定は好みによると思います。yhrさんのコメント と似ていますが、非ログイン時とログイン時、署名と履歴でタイムゾーンが変わるとややこしいと思ったのでタイムゾーンの設定は、UTCにしています。氷鷺さんがなぜ修正されているといえるかは、利用者‐会話:氷鷺/各言語版の標準時が答えになると思います。最も問題になるのは、署名のタイムゾーンだと思います。$wgLocaltimezoneには署名(~~~~と~~~~~)のタイムゾーンとLOCAL系の変数(マジックワード)と#timel条件文と$wgLocalTZoffsetが依存しています。REVISION系の変数(REVISIONIDとREVISIONUSERを除く)は、$wgLocalTZoffsetに依存しています。システムメッセージで使われるタイムゾーンは、$wgLocalTZoffsetと個人設定のタイムゾーンに依存しています。#timelの出力には一部誤りがありました (bugzilla:33454)。#timeと#timelには、問題があります。Help:条件文には誤りがあります。余裕があったら修正します。ウィキペディア日本語版でJSTが使われているところは、Wikipedia:Bot作業依頼/定期作成ページのメンテナンスWikipedia:月間新記事賞Wikipedia:月間強化記事賞があります。TriglavさんがBotについて述べていらっしゃるのは、井戸端の話題と翻訳依頼の掲載期限切れのものの除去のことだろうと思います。mw:Extension:TimezoneSelectorは、(動作に影響しない間違いがありますが)完成したのでよかったら使ってみてください。Pending changesのタブが表示されている場合はそちらが最新版です(荒らされているときを除く)。--Burthsceh会話) 2013年5月6日 (月) 06:06 (UTC)リンク修正。--Burthsceh会話2013年5月6日 (月) 06:11 (UTC)[返信]

投票

[編集]

念のため意見をいただく期間を設けましたが、やはり「JSTにしなければならない」(そしてあらゆる反論を黙らせるほど強力で客観的な)理由がないのと同レベルで、「UTCでなければならない」それも存在しないようです。我々古参?のUTCへの慣れや精神論は、逆のレベルで言えば「独仏とか主な所が現地時刻なんだからjawpもそうすべき!」あたりに該当するものでしょう。メインページの案と同じで、結局のところ「個人的」な好みなんですよね。(まぁ、そういう少数の古参の好みや慣れはなるべく排除してしまって、大多数の新人やIPユーザや閲覧者の利益を優先すべきというのがこの提案の目的なのですが)

そろそろ投票で結論を出したいと思います。17名の方からご意見をいただいていますが、そもそも「少人数の、井戸端で発言する程度に慣れた利用者」が議論で結論を出して良い問題ではありませんので。今回の場合、言ってしまえば「私たち以外」の――井戸端に出てくる程度に慣れた古参・中堅よりは新人やIPユーザー、そしてそもそも編集には参加しない(今後するかもしれない)大多数の閲覧者にとってのがメリット・デメリットを焦点にしたものなのですが、かといって、IPユーザや実績ゼロのアカウントの投票を認める訳にもいかないというのがなんとも微妙ではあります。まぁ、メインページ改訂のときのような

投票するアカウントで初めて編集した時から投票開始時までに1か月以上を経過していて(1か月とは投票開始時刻の前月同日同時刻を指します)、その間、標準名前空間(記事名前空間)の編集が10回以上あり、直近3か月間の標準名前空間の編集回数が1回以上あるログインユーザー

あたりが妥当でしょうか。--氷鷺会話2013年4月20日 (土) 05:55 (UTC)[返信]

ちょっと待って下さい。氷鷺さんは本件を個人の好みの問題にしたいようですがそれはいかがなものかと思います。メインページを変更するのと、10年間運用してきたjaWPのデフォルトタイムゾーンを変更することを同レベルで考えているのだとしたらちょっと問題です。投票の提案はあまりに性急すぎます。氷鷺さんは本当にここに出された意見や指摘を充分に検討されたのでしょうか?私にはとてもそうは思えません。--Wolf359borg会話2013年4月20日 (土) 06:24 (UTC)[返信]
基本的には想定内といいますか、見覚えのあるものが多いですからね。まだ早いというのなら待つのは構いませんが。そうですね、たとえば、10年という数字には何の意味もありません。正確には、まぁそもそも10年を長いと言うのかは置いておくとしても、ただ10年間続いたということにはプラスの意味はありません。それは本当に実績かもしれないし、悪しき伝統とか悪弊とかかもしれませんよね。10年間存続した記事が、ただそれだけの理由で削除を免れることがあり得ないように、長く続いたことが良いこととは限りませんし、考慮すべき点ではありません。--氷鷺会話2013年4月20日 (土) 09:19 (UTC)[返信]

反対が多い状態で、提案者が投票を持ち出すのはいかがなものかと思います。今現在は賛成3(氷鷺さんを入れて4)、反対7、賛否を入れていない人はたぶんどちらでもいいのでしょう。-miya会話) 2013年4月20日 (土) 15:15 (UTC)文言微修正。--miya会話2013年4月20日 (土) 15:17 (UTC)[返信]

コメント 投票を否定する割にはこんな所での(しかも意見内容無視での)票数で決めてしまうというのも矛盾した奇妙な話ですし、『賛否を入れていない人はたぶんどちらでもいいのでしょう』は勝手な想像に過ぎず、仮に大多数が「どちらでもいい」という意見であれば否定の根拠にはなりません。反論なら反論として成立するコメントをお願いします。--氷鷺会話2013年4月22日 (月) 14:35 (UTC)[返信]

(とりあえずこの位置にコメントします)性急というのは単に時間の問題ではありません。氷鷺さんは今の状態のまま少し待つだけで投票を行うべきと考えているのでしょうか?はっきりと申し上げておきますが、氷鷺さんが「想定内」「見覚のある」と思ったり、反対意見を取るに足らない「精神論」と思い込んだところでそれは何の意味も持ちません。氷鷺さんは本件の提案者であり、コミュニティに提案を理解して賛同を得る側の立場であることを忘れないでください。氷鷺さんにとって当然であっても、周りはそうは考えていないということです。UTCとUTC+9どちらが良い悪いという話でも、10年間続いたからという話でもありません。システムデフォルトを変えるということはそれだけでリスクを孕んでいます。その心配が払拭され、提案が有効かつ必要なことであると見極める必要があります。

まずは、ここに出された意見や指摘を整理し、それらについて検討した結果を誠実にお答えいただくというプロセスが必要でしょう。それを経て本件が単なる利用者各自の「好みの問題」にまで落とし込められたなら、その時に投票を実施すべきです。その際に使う参考資料としてWikipedia:井戸端/subj/JST化について/別紙は甚だ不適切でありますから、中立的にメリット・デメリットが示されている資料を作成する必要があるでしょう。ちなみに、「JST化」という表現は誤解を与えますので改めたほうがいいでしょうね。実際に的外れなコメントをされる方もいらっしゃいましたし。ご検討お願い致します。--Wolf359borg会話2013年4月20日 (土) 17:15 (UTC)[返信]

コメント 現地時刻を使うということ、UTCから現地時刻に移行するということは、世界各地のウィキペディアンが既に行ってきた「実績」のあることであり、jawpの利用者だけが他言語版の利用者に比べ著しく劣っている訳でもない限り、少なくとも致命的な問題ではなく、乗り越えられない壁でもない筈のものです。ドイツ人、フランス人、イタリア人、オランダ人、ポーランド人、スウェーデン人、ノルウェー人、フィンランド人、韓国人、タイ人(※ ○○語話者ではなく○○人)……彼らには出来た(そして今も出来ている)ことが我々には「不可能」なレベルというのは不思議な話ですよね(仮に欧米人は時刻の換算に慣れている云々とか言えば、日本人は逆なわけですから尚更妙な話)。致命的な問題というのは本来存在せず、何か致命的に「JSTに出来ない」問題があるとしたらそれは我々jawpユーザーの問題です。jawpがUTCというのは、海外と多少取り引きがあるからといって、会社全体で……大多数の英語を使わないはずの社員やアルバイトや清掃業者や出入り業者・来客にまで英語の使用を強制する日本企業、みたいなものです。英語が流暢で仕事に必須な人間には良いけれども、大多数にはただただ迷惑。
中立的では無いからといって具体的なところをぼかして反論するのは誰にでもできます。中立的でない、甚だ不適切な内容のままであれば、とうに改名されてしまっているでしょう。あなたの発言こそ、甚だ非中立的で不適切です。架空の問題点を指摘するのではなく、実在の問題点を挙げるようお願いします。--氷鷺会話2013年4月22日 (月) 14:35 (UTC)[返信]
コメント 私はJTC化に賛成です。「システムデフォルトを変えるということはそれだけでリスクを孕んでいます。」という意見には、「日本に合わないシステムデフォルトのままでは、それ自体が日本語ウィキペディアのユーザーにとってのリスクです。」と反論できます。結局は、氷鷲氏のおっしゃるように「好みの問題」ですね。UTCにこだわる人の言うJTC化のデメリットとは、実際の多くのユーザーにとってのデメリットというより、各言語版の寄り合い所帯のウィキペディアを世界プロジェクトと誤認あるいは幻想し(国連を地球連邦政府と幻想するのにちょっと似ています)、その「象徴」のUTCを変えたくないがために、その理由付けとして作り上げられたデメリットですね。
なお、今回JTC化が見送られたとしても、個人設定のガジェットで変更できるJTCの表示を、もっとスッキリした「2013年4月20日 (土) 17:15 (JTC)」に変えられないものですか?現行のは要らない表示がゴテゴテ付いていて使う気になれません(よって自分は今はUTCのままです)。少々面倒な方法のオプションもありますが(UTC+9)は変えられず、当日・前日の場合は「今日・昨日」で表示されます。これが解決されれば、現行のままでも良いかなとは思います(投票があればJTC化に入れますが)。--123.220.2.150 2013年4月21日 (日) 05:25 (UTC)[返信]
すみません。不勉強で申し訳ないのですが、「JTC」というのは、何でしょうか、ここでずっと「JST」と略されている「日本標準時」と同じものと考えてよろしいのかとは思いましたが、念のため確認です。あるいは、例えば、当面は現実味がないとはいえ、サマータイムなどが導入されても変動しない「東経135度上の天文時」のことをこう言ったりするということなのでしょうか? ご教示いただければ幸いです。--山田晴通会話2013年4月21日 (日) 06:56 (UTC)[返信]
JTCは気にしなくっていいいです。以前よりjawpではJSTをJTCと書くという間違いが多くあります。実例で言うと、123などがあります。想像するにUTCJSTの意味を知らず、みんなJ何とかって書いてるから多分JTCでいいんだろうということでしょう。ここで私が指摘してたのはこういったことですが・・・。--Vigorous actionTalk/History2013年4月21日 (日) 07:18 (UTC)[返信]
数十かせいぜい100くらいの数で「多く」なのでしたら、たとえば「ウィキペディアは全てUTC」みたいな誤解による誤りも「多く」あるということになります。--氷鷺会話2013年4月22日 (月) 14:35 (UTC)[返信]
私が指摘した後に、さっそく「JST化」を理解されていないと思われるコメントが寄せられました。もし投票をする場合には「JST化」という用語ははなはだ不適切であることが証明されたようです。--Wolf359borg会話2013年4月21日 (日) 07:33 (UTC)[返信]
JST化を理解していないというコメントなら、もっと上のほうに該当するものがありますが、ここのそれは違います。ただ名前を(「シュミレーション」のように)間違えて覚えていただけのコメントと、それを見て自分が間違いだと混乱したコメントがあるだけです。この問題の違いが分かりますか。--氷鷺会話2013年4月22日 (月) 14:35 (UTC)[返信]
賛成 投票を実施することそのものには賛成します。氷鷺さんがおっしゃるように、井戸端で議論を追っていてそこに意見表明を出来る人はほとんどがウィキペディア日本語版に慣れたUTCにも慣れた人たちであろうことに異議はありませんし、それなら投票という簡単に意見表明をできる形でコミュニティー全体の動向を探るのは悪くないことでしょう。ただ注意しなければならないのは、投票はあくまで投票であって合意形成ではないこと(合意形成時の判断材料)で、結果を受けてからの再議論を前提としていることを明確にすべきです(特にjawpに慣れてない人たちにも積極的に参加して欲しい調査投票ならなおさら)。もちろん「リソースの無駄もっと他の有意義なことに使え」という意見も出てきそうですが、投票ページ等の用意は「無駄」と思わない人がやりますし、投票編集がそこまでリソースを消費するわけではないのですから、やるだけやってみては?--青子守歌会話/履歴 2013年4月22日 (月) 02:09 (UTC)[返信]
反対 もちろん投票という手段自体は否定いたしません。利用者の好みに委ねるという状況になったなら、そうするべきでしょう。また、議論の参考とするための世論調査としてであればよいでしょう。しかし、氷鷺さんが投票を言い出した目的は「そろそろ投票で結論を出したい」ですし、そもそもこの井戸端も「念のため意見をいただく期間を設けました」ということに過ぎないようです。一応、形だけ意見は聞いておくけど考慮する気など無い、そういうことなのでしょうか。なぜそんな事の進め方をなさるのか、私にはちょっと理解出来ません。このような状況で結論を出すための投票には明確に反対であると申し上げておきます。まずは、私のコメントを検討していただけないでしょうか。--Wolf359borg会話2013年4月22日 (月) 10:44 (UTC)[返信]
コメント 投票についてですが、まずそもそも私が納得しなければならない理由がないように、Wolf359borgさんが納得しなければならない理由もないということはよろしいでしょうか。反対が一人いたら駄目、という性質ものではないということは理解されているでしょうか。そして、仮に、これからの投票結果を結論としないということであれば、もちろん、UTC支持が圧倒的であったとしても、UTCで現状維持と結論付けることはあり得ないということです。反対派…UTC維持の立場から考えると、むしろ「投票で決めてしまえ」とでも言ったほうが簡単に片付く気もするのですけどね。投票は結論とはしないという主張をしてしまって大丈夫でしょうか。自分に都合の良い投票結果は正しくて、自分に都合の悪い投票結果は誤りだ、…という方はたまに居ますので、そういう問題を起こされるのはちょっと勘弁願いたいところです。--氷鷺会話2013年4月22日 (月) 14:35 (UTC)[返信]
まず、上の氷鷺さんの発言についてコメントさせていただきます。
投票についてですが、まずそもそも私が納得しなければならない理由がないように、Wolf359borgさんが納得しなければならない理由もないということはよろしいでしょうか。
よろしくありません。と申しますか、何をおっしゃっているのか理解しかねます。なぜ一個人の納得という矮小な話にすり替わっているのでしょう。この場での指摘・反論にまともに答えていただけないまま、反対意見が複数出されている状況を一切考慮せずに、投票を(しかも本件提案者自身が)提案するのは不適切です。
反対が一人いたら駄目、という性質ものではないということは理解されているでしょうか。
この反対というのは、この井戸端議案に対する反対意見のことでしょうか?それとも投票提案に対する私の反対票のことでしょうか?もちろん、どちらも反対が一人いたから駄目ということはありません。しかし、前者の場合で言えば反対意見は私一人だけではなく複数出されており、賛成意見を上回っています。後者の場合で言えば賛成1に反対1です。これでコミュニテイに一定の賛同が得られたと見る人はいないでしょう。しかも、青子守歌さんの賛成意見にしても「結果を受けてからの再議論を前提としていることを明確にすべき」とおっしゃっています。つまり、結論を出すことを目的とした新たな投票に賛成意見は出ておりません
そして、仮に、これからの投票結果を結論としないということであれば、もちろん、UTC支持が圧倒的であったとしても、UTCで現状維持と結論付けることはあり得ないということです。
この井戸端では賛成票、反対票という形式で意見を表明しているに過ぎません。ウィキペディアではコミュニティの動向を調査投票で行うことがありますが、合意に至る努力をすることが強く推奨されているはずです。むろん、この文言は手引書レベルではありますが、言わんとするところはおわかりいただけるはずです。本件提案者は多数の反対意見や指摘に耳を傾けるべきです。そして広くコミュニティ一般に告知して投票を行うなら、それ相応の準備が必要です。判断材料となる資料が必要となりますが、現状の別紙資料はJST化推進の立場に沿った内容のみでメリット・デメリットがきちんと示されていませんWikipedia‐ノート:井戸端/subj/JST化について/別紙#改名提案にもコメントしました)のでとても使えません。ですが、一般利用者の動向をすくい取って議論の参考にするレベルなら問題無いだろう、そう申し上げただけです。
反対派…UTC維持の立場から考えると、むしろ「投票で決めてしまえ」とでも言ったほうが簡単に片付く気もするのですけどね。
そうやって賛成派、反対派などと安易に対立の構図にして煽るようなまねは慎むべきかと思います。UTCが良い、JSTが良いだけでなく、変更すること自体慎重になるべきという意見もあるのです。単なる勝ち負けの問題ではありませんし、繰り返しますが合意に至る努力をするべきなのです。
投票は結論とはしないという主張をしてしまって大丈夫でしょうか。
すでに述べたように、氷鷺さんが提案されている投票とこの井戸端での賛成意見、反対意見の表明は全く別の話です。氷鷺さんはここで出た意見に真摯に耳を傾ける必要があります。
自分に都合の良い投票結果は正しくて、自分に都合の悪い投票結果は誤りだ、…という方はたまに居ますので、そういう問題を起こされるのはちょっと勘弁願いたいところです。
全く同感です。変えること自体の不安が払拭されるのであれば、コミュニティが望むものが選択されるべきでしょう。ちなみに、この井戸端では反対意見の方が上回っておりますが、当然、自分に都合が悪いからといってそれを黙殺するようなことはなさりませんよね。
氷鷺さんは本件提案をまじめに進めるつもりがあるのか疑問に思うところがあります。提案内容をコミュニティに理解してもらい、疑問点を払拭し、賛同を得ようという真摯な姿勢が感じられません。この井戸端も形式的に念のため意見をいただく期間を設けただけで、出された指摘事項や反論に真摯に向き合おうとせず、安易にそろそろ投票で結論を出したいなどとおっしゃる。氷鷺さんの言行はいたずらに反感を生じさせるだけです。実に残念なことです。「ウィキペディアは多数決主義ではありません」をお忘れでしょうか?--Wolf359borg会話2013年4月23日 (火) 15:52 (UTC)[返信]
コメント 真摯という言葉をいい加減に濫用するのはお止めください。真摯でない真摯でないなどと連呼したところであなたが優位に立てる訳ではないことくらいお分かりでしょう。本質的なところで反論ができないからといって無理に非難をしようとするからそういう発言になってしまうのです。一個人の納得という矮小な話しかなさっていませんし、たかだか井戸端の十数人の発言のみでコミュニティを代表・代弁するかのような発言は不適切かつ虚偽であり、『現状の別紙資料はJST化推進の立場に沿った内容のみでメリット・デメリットがきちんと示されていませんのでとても使えません。』という主張は、あなたのごく個人的な、そして正しくない、単純な事実を「促進派の発言」に陥れたいだけの主張に過ぎず、それこそ誰も賛同していません。「偏向だ!」と感じてしまったのであれば、それはただ、あなたの思考が事実を拒否しているということになります。投票を否定し議論による合意形成をはかるという原則は確かにありますが、それには、「議論でまとまる程度の」一部の少数の人間だけで結論を下してよい案件であり、案A と 案B という両論について妥協・中間・譲歩などの案が検討可能な代替案として成立し得る場合という前提があります。なるべく多くの、一般の、普通の、古参に限定せず新人や低頻度の参加者をも含めたコミュニティ全体の意見を問うべき案件で、かつ妥協・中間・譲歩などといった案が検討可能なレベルで成立し得ない案件では、議論で合意形成をという主張を繰り返すのはただ「やめろやめろ」と叫ぶだけの妨害と同義です。--氷鷺会話2013年4月24日 (水) 15:48 (UTC)[返信]
コメント わたくしはJSTの導入は個人的には賛成でございます(ただし、日本だからJSTでよい、日付が面倒程度の考えでしかございません)。しかし、それが「システムの問題」であるなら、それらがもたらす直接的な問題はもちろん、間接的まで問題までを十分に検討検証し、だれでもが分かる議論の内容にし、それを皆様にご提示する必要を非常に感じるところでございます(どんなデバイスからの閲覧でも影響がないのかなど)。そもそも、UTC+9=JSTではございません。「議論でまとまる程度の一部の少数の人間だけで結論を下してよい案件」でないなら、当然のことといたしまして有効投票数は真の全投稿者を十分に反映させうる投票数と十分な期間を、科学的(統計的)に裏打ちされた思想の上でお考えのことと存じますが、ご提案の正確性の根拠を最低限のこととして、ご説明くださいますように。私からも氷鷺さまには真摯な態度での進行をお願いいたします。--HASIDATE会話2013年4月25日 (木) 12:23 (UTC)[返信]
  • 上のHASIDATEさんのコメントのインデントを調整させていただきました。
コメント なにか「真摯」という言葉が独り歩きしてしまってる感がありますが…もちろん、そのような言葉を使わずとも同じ事なわけです。言葉尻をとらえて、これ幸いと私のコメントをなかったことにして話を逸らすというのはいかがなものでしょう。それこそ反論ができないための苦し紛れのようにさえ思えます。ここまで話が噛み合わないやり取りは不毛に思えてきました。早く本題の議論に戻るべきだと思うのですが、いかがでしょうか。指摘や意見をスルーし、都合の悪いコメント(多少難ありではありましたが)が書かれると議論妨害と主張し、新たな賛成意見が書き込まれなくなるといきなり投票を持ち出し、そこで反対されるとまたしても妨害だとおっしゃる。賛同を得る方向ではなく対立を深める方向に振舞われております。これは賢明なやり方ではないでしょう。
さて、私なりに氷鷺さんのコメントを読み砕きまして、おそらく具体的な指摘を求めてるのだろうと解釈しました。以下に、現状の別紙資料が井戸端資料には使えても投票のための資料としては不適切であることを示します。
  • 「JST化」というタイトルは誤解を生じさせる恐れがあり検討が必要です。(実際この井戸端でも混乱が見られました)
  • 概要の説明は見た目がどう変わるかだけでなく、実際にシステムにどのような変更がなされるのか正確に示す必要があります。閲覧性を考慮するなら別紙にしても良いでしょう。
  • 「日本語話者にとっての利便性(日本語話者の分布)」これは提案のメリットを訴えている部分です。データが示されており、問題ないでしょう。
  • 「すでにjawpはJSTで動いている」JSTで運用されている例を示しているだけですので良いでしょう。ただし、「JST で運用されている所は少なくありません」は過大な印象を与える恐れがありますので、「所があります」に修正するか、正確に具体的な例を列挙するべきです。
  • 「してはいけない理由はない」で、他言語版および姉妹プロジェクトで採用されているタイムゾーンの状況の表が示されています。ですが、この表は全世界のプロジェクトがUTCで統一されているわけではない、ということを示すのみで、「JSTに変えていけない理由はない」ことを示す論拠には成り得ません。論拠とは関係ない参考資料として提示するべきでしょう。
  • ここが一番重要なことですが、変更に伴うリスクやデメリットに関して「テンプレートとかに悪影響は?」のわずかな記述しか見当たりません。現時点でこの井戸端において、変更に伴う一時的な混乱の懸念、稼働中のBotスクリプトへの影響、10年間運用してきたデフォルトを変えることによる想定しない影響への懸念、「ネット選挙解禁」といったややこしい時期にリスクを増やすべきでない、といった意見が出されているわけでして、リスクやデメリットを検討した上で正確な情報を提示すべきでしょう。
最後に、最終結論を出すための投票に賛成している人は1人もいないことを確認しておきます。--Wolf359borg会話2013年4月25日 (木) 14:39 (UTC)[返信]
コメント 1つ誤解(誤用)されていると良くないので明記しておきますが、ここで私が「結果を受けてからの再議論を前提としていることを明確にすべき」と書いたのは、「投票結果を無視しろ」という意味ではありませんし、ましてや「投票結果で結論を出すな」と言っているのではありません。きちんと条件の整った正確な調査投票の結果は、その結果がほぼそのままコミュニティー全体の意見を反映している(意見の割合を示している)と見なせるはずです。その結果によって例えば圧倒的多数の支持を集めた選択肢がある場合は、あえて覆さなければならないほどの非常に強い理由があって誰もがその圧倒的多数意見を却下することに納得できるなら別ですが、通常はその選択肢を実現するために動くことになるでしょうし。圧倒的多数ではなくとも、少なくともその後の議論において「投票でどれぐらいの支持があった/なかった」はとても重要な判断材料にすべきです。ですから、結果を求める(直結し即断されるという意味ではなく、結果を出すための強固で確固たる判断材料を求める)ための投票というのはもちろんアリでしょうし、そのような投票をも私は支持します。ただし最初に書きましたが「きちんと条件の整った正確な調査投票」である必要がありますから、少なくともここで出た賛否コメントの、あるいは賛否両側がそれぞれ書いた主張のまとめぐらいは投票者に示さなければならないでしょうね(というか、/別紙が賛成側に偏っているとするなら、反対側は反対側で別のどこかに書けばいいのでは?)。--青子守歌会話/履歴 2013年4月26日 (金) 21:18 (UTC)[返信]
コメント 私は青子守歌さんの発言を誤解していたつもりはなかったのですが、不適切な引用をしてしまっていたようです。その点についてはお詫び致します。私の本意について明記しておきます。まず、私は「投票結果を無視しろ」という主張はしておりません。それどころか、氷鷺さんの「自分に都合の良い投票結果は正しくて、自分に都合の悪い投票結果は誤りだ、…という方はたまに居ますので、そういう問題を起こされるのはちょっと勘弁願いたいところです」という発言に対し、「全く同感です」とお答えしています。また、投票という手段自体に反対しているわけでもありません。この下でTriglavさんがおっしゃっておられる「純粋なる需要」を調査することはアリだと思っています。また、検討を重ねた後の最終決定は井戸端ではなく告知した上での投票になるでしょう。しかしながら、氷鷺さんが投票を持ち出してきた意図はそのようなものとは到底思えません。ですから私は反対しているわけです。「きちんと条件の整った正確な調査投票」が行えるように準備して投票を行うのは良いと思います。あと、この井戸端は、「ご意見をお願いします」だったのに、いきなり賛否の応酬になってしまったこと、(1)一般利用者の利便性を高めるためにJST表示を提供すべきか?(2)それはどのように実現すべきか?(3)それによりどのような影響やデメリットが生じるか?という論点が一緒くたになってるのが良くないなあと思っています。まずは、出されたコメントのまとめをすべきでしょうね。--Wolf359borg会話2013年4月27日 (土) 16:10 (UTC)[返信]
コメント この投票で、(移行のリスクを無視した)純粋なる需要というものが知りたいです。その結果によって、リスクに向きあう価値があるかを反対派の方たちに判断してもらいましょう。もちろんその反対もあり得ます。
ちなみに私の手持ちのBotは修正しますので気にしないでください。そのほかについては、文章を切り抜いているような作業をしてるBotを洗い出して担当者に影響がないか呼びかけてみましょう。--Triglav会話2013年4月27日 (土) 14:08 (UTC)[返信]
コメント 本日、猪瀬直樹東京都知事が政府に対してJSTを2時間早める提案を行います[1]。ウィキペディア日本語版のJST化の問題はこの提案の動向を見極めてから改めて検討すべきものと思います。--むじんくん会話2013年5月22日 (水) 02:40 (UTC)[返信]