アカウント名:
パスワード:
>なお、これとはまったく関係はないが、例えば「年4桁+月2桁」の数字6桁で年月を表現するルールを採用している場合、2020年を迎えた現在それが「年2桁+月2桁+日2桁」との表記との区別がつかないという問題も指摘されている。
全く関係ないけどさ、日本の場合は年・月・日の順序は変わらないけど英語圏では
MM/DD/YY 01/14/20DD/MM/YY 14/01/20
って二種類の表記があるけどコレって混同しないのかな?
そもそもの問題として一番頻繁に数字が変わるケタを右側に持ってこない理由がいまいちわからない。なんで年を最後に宣言するんだ?
省略すれば現在の月/年と考えれば合理的ではある。DD書いてる途中で敵が攻めてきたらやばいじゃん。年なんてめったに変わらないものは後回しさ!
敵が攻めて来て居るのなら日付確認以前に対処しろや。
ジョークに対してナンセンスだのう
省略して月日だけ書くならいいけど、年を書くなら先頭に書いてほしい。(年も一応書いておくか でも重要じゃないから最後な)ってのが一番イヤ
タレコミ文の末尾で「なお、これとはまったく関係はないが」とわざわざ但し書きをつけて関係ない話を始めるから全く関係ないコメントが出てきてしまう。まさに蛇足。
そもそも「数字6桁で年月を表現するルールを採用」してるんだからそのルールに従って読めばいい。
ルールを知らない人は年月日の読み方がわからなくなる?そんなの当たり前。略記法なんだから、情報を落として文字数が少なくなるようにしてるんだから、曖昧さが出て当然。
> なんで年を最後に宣言するんだ?
英語はその順番で書くから。以上
アメリカ:MMDDYYYYイギリス:DDMMYYYYカナダ:YYYYMMDD
英語だからこの順番なんて決まりはねぇよw
NATO方式に統一しろ (YYYYMMDD)ヤードポンド法は滅ぼすべき
いや、ISO (YYYY-MM-DD)かな。
アメリカは事実上NATOの本体。つまりアメリカ方式は事実上のNATO方式。
moon
うさぎ
むつき
それだけだとYY/MM/DDとDD/MM/YYを区別できないのでは?
紛らわしいから、Jan、Febとか月の英単語短縮になってるのはよく見る。特に国際的に展開してるとこ。たぶん、国内向けオンリーの場合はその国の表記でやってるんじゃね。
最後の行については、そもそも言いたいことを先に持ってこい(Subject・Verb・Object)な文化だし、合理的といえば合理的かも。日本語みたいに、主語から修飾語や目的語がダラダラ続いて最後に肝心の動詞がある方がマイナーな気が。
住所も日本とは反対でしょ。番地から国へ(小から大)。まぁこれに関しては、日本の大きいところから狭めていく方がわかりやすい。途中でも場所が想像できるけど、番地やストリートから言われても「どこのだよ」って。
同じ英語なのに、米英で細かい違いが多いのが面倒。この日付のように、致命的な誤解を生む違いもあるし。
MS の DOTNET Framework では日本のロケールでは月の短縮名は「1月,2月」とか「睦月,如月」とかではなく、「Jan,Feb」なのよね。
で英語にも対応ってことでやってたらロシアで動かないとクレームが来たことがある。
DOTNET Frameworkとやらは知らないけど、.NET Frameworkならロケールって言葉はほとんど使われなくてカルチャって概念で扱うし、ja-JPに対応するDateTimeFormatInfoのAbbreviatedMonthNamesは1,2,...を返す。Jan,Feb,...になったのは多分InvariantCultureが紛れ込んだんだろう。
オフショア丸投げではなく、海外に開発支部がある某ソフトハウスで上がってきたプログラムがこっちでテストするとエラーが出るソースコードを見ると月をToStringして"Jan", "Feb", "Mar", ... と比較していたことが確かに英語圏だとこれで動きそうな感じがしたが
# いや、月だけ取り出してくださいよ整数で
全く関係ないけど、ドイツ語の分離動詞を習ったとき、最後まで読まないと分からないから日本語は難しいとか嘘やんと思った。
全く関係ないけど、日本語はその場の空気も読まないといけませんからね・・・
全く関係ないのに、いちいち日本語をディスっていく人って……
空気を読まなくてもいい言語なんて存在するの?
#3744863ですけど、別に日本語を否定したり軽蔑しているわけではありませんよ。まあ、確かに「空気を読まないといけない」と言うのは不適切でしたね。今海外にいるんですけど、こちらの人はYes、Noをはっきり言いますから、それに比べて日本人と話すと言葉を言葉通りに受けてはいけない時もあり、日本語は難しいなと感じる事がありましたので、そういった事を表現したかっただけです。あと、文頭の「全く関係ないけど」もいりませんでしたね。# まあ、何を言っても言い訳でしかないですし、私の言葉の拙さが招いた結果ですから、何を言われてもしょうがないですけど・・・
> 今海外にいるんですけど、こちらの人はYes、Noをはっきり言いますから
まあ、東海岸のロイヤーは「Yes、Noをはっきり」言わずに、京都人なみの婉曲表現を駆使すると聞いたことあるので、海外でもいろいろなんじゃないですかね。
特に狭いコミュニティーほどハイコンテキストなコミュニケーションが求められる、というのはありそうですが。
言葉通りに受け取っちゃあかんのはどこの国も同じ誉め言葉が皮肉なんて向こうはお得意でしょう?
「No.」の意味で「I'm OK.」とか「Fine.」とか言いますし、ケースバイケースですね。
具体的な地域を出さずに「海外にいるんですけど」とか言い出す時点で妄想君でしょう
最近、Not no〜とかDon't no〜とか、どっちのこと言ってるのかわからない文章が英語で増えてるけど(実際ノー側の意味だが)、まったく日本で起きることは海外でも起きるって言う区別つけられないんでしょうね。ああ恥ずかしい。
年月日の順番はフリーダムなのに、時分秒の順番が時分秒以外のケースって見ないなぁ
12時間表記の際の11pm/午後11時みたいなのはあるね。シャバダバダバダバ。
RFC3339 [biglobe.ne.jp]に準拠するなら年月日順、年は4桁。区切りはハイフン。「YYYY-MM-DD」であって「YYYY/MM/DD」ではない。なんでスラッシュを使うんだ?
慣習ってやつじゃなかろうか。曜日についても、週の最初は月曜って規定されてるけど、日本だと日曜始まりのカレンダーの方がよく目にする。
> 週の最初は月曜って規定されてるけど
こらこらこら、さらっと嘘を書くな。ISOでは実務上そう扱うというだけでしょ。
なんでスラッシュを使うんだ?
日本人の一部で、ハイフンは期間を表現するために予約されているからです。
小数点が.か,かみたいな物でその辺も国によってちがうんだよ。カナダはYYYY-MM-DDだけど、日本はYYYY/MM/DD、米国はMM/DD/YYYYみたいに。
国際単位系「"."も","もどちらも小数点で、桁区切りは空白だぞ」
Java/Perl/Ruby「数値の桁区切りに"_"を使えるようにしたぞ」
C++/電卓「桁は'で区切るぞ」
>Java/Perl/Rubyc#(7以降)も仲間に入れてあげて…Java/c#はあまり使われてない気がする。
「YYYY.MM.DD」ってピリオド区切りにする文化も(一部では?)ありますし。
それは規格を作るときの調査で、欧米の各ロケールで順番はまちまちだけど、スラッシュで区切る慣習が概ねだったので、規格では敢えて非一般的なハイフンを採用した。日時文字列を見るとき、スラッシュで区切られていればロケール依存の慣用並びであることが予想でき、ハイフン区切りであれば年月日並びであることが予想できる…のだと云う事実は知らない。
VBA等で DateValue関数を利用して、文字から日付に変換 [microsoft.com]するときに起きる落とし穴ですね。月入力で1~12かチェックしないと↓みたいな事が起きる。
DateValue("12/12/13")=2012/12/13(YY/MM/DD)DateValue("12/13/12")=2012/12/13(MM/DD/YY)
# ロケール固定になるけど、
ユニークなIDが先、所属グループが後西洋はそういう順番だろ名前だって、個人名が先で、後から家族の名前である姓がくる
住所だったら番地、市区町村、州県名、国名メールアドレスはID@ドメイン名ドメイン名も組織名から後になるほど大まかなまとまりになる
むしろ情報量が少ない要素を先に持ってくる日本式のほうが効率が悪いとも言える。最後まで聞かないと分かんないじゃん
逆におおざっぱな情報でいい時は途中で切ればいいから効率的ともいえる。
URLはドメイン名とそれ以後で急に順番が逆になるよね。
ドメイン名部分は小→大なのに、それ以後は大→小。
http://www.example.jp/2020/08/15/someone-arredted [example.jp]
ドメイン名をあの順番にしたのを設計者が後悔してましたね。
ティム・バーナーズ=リーが語る「WWW に対する 2 つの後悔」 | スラド IT [it.srad.jp]
これって要は、向こうの人だって大→小の方が効率的だって考えてるって事なんじゃないの?
そういう纏まりで情報として扱うのって大体一覧でしょ。見づらいじゃん。
図書館とかで、1巻だけ集めた棚、2巻だけ集めた棚とかじゃ効率悪いでしょ。
住所だって、届ける際は結局大きなくくりから見ていくんだから、先に書いてある方が効率的。個人名なんて、家に届いてからしか関係ないし。
ソートやグルーピングする際も、面倒臭い処理しないといけないし。
>住所だったら番地、市区町村、州県名、国名
番地部分は、「番地→通りの名前→アパート名→部屋番号」みたいに大→小で書くじゃん。大まかなまとまりが後に来るなら、部屋番号から書くべきなんじゃないの?
近距離の郵便配達利用者が圧倒的に多かった時代の名残なんじゃねえの。エリア拡大に伴って付け足していっただけでしょ。
>最後まで聞かないと分かんないじゃん
最後まで聞かなくても全部わかるならそもそも言う必要ないよね。言う必要ないなら聞かなくてもいいんだから何の問題もない。
日本でだって、市内で
手書きの時代の慣習はまあいいんですよね(住所は他のコメントにもあるように必ずしも細かい順じゃないのでやめてほしいけど)。デジタル化というかIT化の時に、sortするのにものすごく効率悪くなるんだからデータ上はyyyymmddの類になってもおかしくないのに、それでもddmmyyyyとかmmddyyyyとかyyyyMMMddとかMMM dd, yyとか使いたがるのが理解できん。(まあ日本でも8.5 '02みたいなイカレた表記があるし、漢字とかsort時の検索性が貧弱だったりするけれども)文字幅もプロポーショナルフォントが多くて、表や図にした時に揃ってないからすっごい見づらいんだよなぁ欧米式。
scheme://ユーザ名@パスワード:ホスト名.ドメイン名.トップレベルドメイン:ポート番号/親ディレクトリ/子ディレクトリ/孫ディレクトリ …
ドメイン表記とディレクトリ表記の順番はめちゃくちゃやがな、と思っていた。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
なぜ年月日ではないのか (スコア:2)
>なお、これとはまったく関係はないが、例えば「年4桁+月2桁」の数字6桁で年月を表現するルールを採用している場合、2020年を迎えた現在それが「年2桁+月2桁+日2桁」との表記との区別がつかないという問題も指摘されている。
全く関係ないけどさ、日本の場合は年・月・日の順序は変わらないけど
英語圏では
MM/DD/YY 01/14/20
DD/MM/YY 14/01/20
って二種類の表記があるけどコレって混同しないのかな?
そもそもの問題として一番頻繁に数字が変わるケタを右側に持ってこない理由がいまいちわからない。なんで年を最後に宣言するんだ?
Re:なぜ年月日ではないのか (スコア:1)
>DD/MM/YY 14/01/20
>
>って二種類の表記があるけどコレって混同しないのかな?
エンディアンですね
>そもそもの問題として一番頻繁に数字が変わるケタを右側に持ってこない理由がいまいちわからない。
やっぱりエンディアンですね
#本来、MMの部分は数字を使わなかったんでしょうね(Jan,Febとか)
Re: (スコア:0)
省略すれば現在の月/年と考えれば合理的ではある。
DD書いてる途中で敵が攻めてきたらやばいじゃん。年なんてめったに変わらないものは後回しさ!
Re: (スコア:0)
敵が攻めて来て居るのなら日付確認以前に対処しろや。
Re: (スコア:0)
ジョークに対してナンセンスだのう
Re: (スコア:0)
省略して月日だけ書くならいいけど、年を書くなら先頭に書いてほしい。
(年も一応書いておくか でも重要じゃないから最後な)ってのが一番イヤ
これとはまったく関係はない (スコア:0, フレームのもと)
タレコミ文の末尾で「なお、これとはまったく関係はないが」とわざわざ但し書きをつけて関係ない話を始めるから
全く関係ないコメントが出てきてしまう。まさに蛇足。
そもそも「数字6桁で年月を表現するルールを採用」してるんだからそのルールに従って読めばいい。
ルールを知らない人は年月日の読み方がわからなくなる?そんなの当たり前。
略記法なんだから、情報を落として文字数が少なくなるようにしてるんだから、曖昧さが出て当然。
> なんで年を最後に宣言するんだ?
英語はその順番で書くから。以上
Re: (スコア:0)
アメリカ:MMDDYYYY
イギリス:DDMMYYYY
カナダ:YYYYMMDD
英語だからこの順番なんて決まりはねぇよw
Re: (スコア:0)
NATO方式に統一しろ (YYYYMMDD)
ヤードポンド法は滅ぼすべき
Re: (スコア:0)
いや、ISO (YYYY-MM-DD)かな。
Re: (スコア:0)
アメリカは事実上NATOの本体。つまりアメリカ方式は事実上のNATO方式。
Re: (スコア:0)
Re: (スコア:0)
moon
Re: (スコア:0)
うさぎ
Re: (スコア:0)
むつき
Re: (スコア:0)
それだけだとYY/MM/DDとDD/MM/YYを区別できないのでは?
Re: (スコア:0)
紛らわしいから、Jan、Febとか月の英単語短縮になってるのはよく見る。特に国際的に展開してるとこ。
たぶん、国内向けオンリーの場合はその国の表記でやってるんじゃね。
最後の行については、
そもそも言いたいことを先に持ってこい(Subject・Verb・Object)な文化だし、合理的といえば合理的かも。
日本語みたいに、主語から修飾語や目的語がダラダラ続いて最後に肝心の動詞がある方がマイナーな気が。
住所も日本とは反対でしょ。番地から国へ(小から大)。
まぁこれに関しては、日本の大きいところから狭めていく方がわかりやすい。
途中でも場所が想像できるけど、番地やストリートから言われても「どこのだよ」って。
同じ英語なのに、米英で細かい違いが多いのが面倒。
この日付のように、致命的な誤解を生む違いもあるし。
Re:なぜ年月日ではないのか (スコア:1)
MS の DOTNET Framework では日本のロケールでは月の短縮名は「1月,2月」とか「睦月,如月」とかではなく、「Jan,Feb」なのよね。
で英語にも対応ってことでやってたらロシアで動かないとクレームが来たことがある。
マクロの基本は検索置換(by y.mikome)
Re: (スコア:0)
DOTNET Frameworkとやらは知らないけど、.NET Frameworkならロケールって言葉はほとんど使われなくてカルチャって概念で扱うし、ja-JPに対応するDateTimeFormatInfoのAbbreviatedMonthNamesは1,2,...を返す。
Jan,Feb,...になったのは多分InvariantCultureが紛れ込んだんだろう。
Re: (スコア:0)
オフショア丸投げではなく、海外に開発支部がある某ソフトハウスで
上がってきたプログラムがこっちでテストするとエラーが出る
ソースコードを見ると月をToStringして"Jan", "Feb", "Mar", ... と比較していたことが
確かに英語圏だとこれで動きそうな感じがしたが
# いや、月だけ取り出してくださいよ整数で
Re: (スコア:0)
全く関係ないけど、ドイツ語の分離動詞を習ったとき、最後まで読まないと
分からないから日本語は難しいとか嘘やんと思った。
Re: (スコア:0)
全く関係ないけど、日本語はその場の空気も読まないといけませんからね・・・
Re: (スコア:0)
全く関係ないのに、いちいち日本語をディスっていく人って……
空気を読まなくてもいい言語なんて存在するの?
Re: (スコア:0)
#3744863ですけど、別に日本語を否定したり軽蔑しているわけではありませんよ。
まあ、確かに「空気を読まないといけない」と言うのは不適切でしたね。
今海外にいるんですけど、こちらの人はYes、Noをはっきり言いますから、それに比べて日本人と話すと言葉を言葉通りに受けてはいけない時もあり、日本語は難しいなと感じる事がありましたので、そういった事を表現したかっただけです。あと、文頭の「全く関係ないけど」もいりませんでしたね。
# まあ、何を言っても言い訳でしかないですし、私の言葉の拙さが招いた結果ですから、何を言われてもしょうがないですけど・・・
Re:なぜ年月日ではないのか (スコア:1)
> 今海外にいるんですけど、こちらの人はYes、Noをはっきり言いますから
まあ、東海岸のロイヤーは「Yes、Noをはっきり」言わずに、
京都人なみの婉曲表現を駆使すると聞いたことあるので、
海外でもいろいろなんじゃないですかね。
特に狭いコミュニティーほどハイコンテキストなコミュニケーションが
求められる、というのはありそうですが。
Re: (スコア:0)
言葉通りに受け取っちゃあかんのはどこの国も同じ
誉め言葉が皮肉なんて向こうはお得意でしょう?
Re: (スコア:0)
「No.」の意味で「I'm OK.」とか「Fine.」とか言いますし、ケースバイケースですね。
Re: (スコア:0)
具体的な地域を出さずに「海外にいるんですけど」とか言い出す時点で妄想君でしょう
Re: (スコア:0)
最近、Not no〜とかDon't no〜とか、どっちのこと言ってるのかわからない文章が英語で増えてるけど(実際ノー側の意味だが)、
まったく日本で起きることは海外でも起きるって言う区別つけられないんでしょうね。ああ恥ずかしい。
Re: (スコア:0)
年月日の順番はフリーダムなのに、時分秒の順番が時分秒以外のケースって見ないなぁ
Re: (スコア:0)
12時間表記の際の11pm/午後11時みたいなのはあるね。
シャバダバダバダバ。
Re: (スコア:0)
RFC3339 [biglobe.ne.jp]に準拠するなら年月日順、年は4桁。区切りはハイフン。
「YYYY-MM-DD」であって「YYYY/MM/DD」ではない。なんでスラッシュを使うんだ?
Re: (スコア:0)
慣習ってやつじゃなかろうか。
曜日についても、週の最初は月曜って規定されてるけど、
日本だと日曜始まりのカレンダーの方がよく目にする。
Re: (スコア:0)
> 週の最初は月曜って規定されてるけど
こらこらこら、さらっと嘘を書くな。
ISOでは実務上そう扱うというだけでしょ。
Re: (スコア:0)
なんでスラッシュを使うんだ?
日本人の一部で、ハイフンは期間を表現するために予約されているからです。
Re: (スコア:0)
小数点が.か,かみたいな物でその辺も国によってちがうんだよ。
カナダはYYYY-MM-DDだけど、日本はYYYY/MM/DD、米国はMM/DD/YYYYみたいに。
Re: (スコア:0)
国際単位系「"."も","もどちらも小数点で、桁区切りは空白だぞ」
Java/Perl/Ruby「数値の桁区切りに"_"を使えるようにしたぞ」
C++/電卓「桁は'で区切るぞ」
Re: (スコア:0)
>Java/Perl/Ruby
c#(7以降)も仲間に入れてあげて…
Java/c#はあまり使われてない気がする。
Re: (スコア:0)
「YYYY.MM.DD」ってピリオド区切りにする文化も(一部では?)ありますし。
Re: (スコア:0)
それは規格を作るときの調査で、欧米の各ロケールで順番はまちまちだけど、スラッシュで区切る慣習が概ねだったので、規格では敢えて非一般的なハイフンを採用した。
日時文字列を見るとき、スラッシュで区切られていればロケール依存の慣用並びであることが予想でき、ハイフン区切りであれば年月日並びであることが予想できる…のだと云う
事実は知らない。
Re: (スコア:0)
VBA等で DateValue関数を利用して、文字から日付に変換 [microsoft.com]するときに起きる落とし穴ですね。
月入力で1~12かチェックしないと↓みたいな事が起きる。
DateValue("12/12/13")=2012/12/13(YY/MM/DD)
DateValue("12/13/12")=2012/12/13(MM/DD/YY)
# ロケール固定になるけど、
Re: (スコア:0)
ユニークなIDが先、所属グループが後
西洋はそういう順番だろ
名前だって、個人名が先で、後から家族の名前である姓がくる
住所だったら番地、市区町村、州県名、国名
メールアドレスはID@ドメイン名
ドメイン名も組織名から後になるほど大まかなまとまりになる
むしろ情報量が少ない要素を先に持ってくる日本式のほうが効率が悪いとも言える。
最後まで聞かないと分かんないじゃん
Re: (スコア:0)
逆におおざっぱな情報でいい時は途中で切ればいいから効率的ともいえる。
Re: (スコア:0)
URLはドメイン名とそれ以後で急に順番が逆になるよね。
ドメイン名部分は小→大なのに、それ以後は大→小。
http://www.example.jp/2020/08/15/someone-arredted [example.jp]
Re: (スコア:0)
ドメイン名をあの順番にしたのを設計者が後悔してましたね。
ティム・バーナーズ=リーが語る「WWW に対する 2 つの後悔」 | スラド IT [it.srad.jp]
これって要は、向こうの人だって大→小の方が効率的だって考えてるって事なんじゃないの?
Re: (スコア:0)
そういう纏まりで情報として扱うのって大体一覧でしょ。
見づらいじゃん。
図書館とかで、1巻だけ集めた棚、2巻だけ集めた棚とかじゃ効率悪いでしょ。
住所だって、届ける際は結局大きなくくりから見ていくんだから、
先に書いてある方が効率的。個人名なんて、家に届いてからしか関係ないし。
ソートやグルーピングする際も、面倒臭い処理しないといけないし。
Re: (スコア:0)
>住所だったら番地、市区町村、州県名、国名
番地部分は、「番地→通りの名前→アパート名→部屋番号」みたいに大→小で書くじゃん。
大まかなまとまりが後に来るなら、部屋番号から書くべきなんじゃないの?
近距離の郵便配達利用者が圧倒的に多かった時代の名残なんじゃねえの。
エリア拡大に伴って付け足していっただけでしょ。
>最後まで聞かないと分かんないじゃん
最後まで聞かなくても全部わかるならそもそも言う必要ないよね。
言う必要ないなら聞かなくてもいいんだから何の問題もない。
日本でだって、市内で
Re: (スコア:0)
手書きの時代の慣習はまあいいんですよね(住所は他のコメントにもあるように必ずしも細かい順じゃないのでやめてほしいけど)。
デジタル化というかIT化の時に、sortするのにものすごく効率悪くなるんだからデータ上はyyyymmddの類になってもおかしくないのに、それでもddmmyyyyとかmmddyyyyとかyyyyMMMddとかMMM dd, yyとか使いたがるのが理解できん。(まあ日本でも8.5 '02みたいなイカレた表記があるし、漢字とかsort時の検索性が貧弱だったりするけれども)
文字幅もプロポーショナルフォントが多くて、表や図にした時に揃ってないからすっごい見づらいんだよなぁ欧米式。
Re: (スコア:0)
内部的に日付データとして持ってれば表現は何だって正確にソートできるだろ
日付を文字列として扱ってる糞なシステムを捨てる方が早い
URIもいびつ (スコア:0)
scheme://ユーザ名@パスワード:ホスト名.ドメイン名.トップレベルドメイン:ポート番号/親ディレクトリ/子ディレクトリ/孫ディレクトリ …
ドメイン表記とディレクトリ表記の順番はめちゃくちゃやがな、と思っていた。