日本のロケールの計算機向き具合＞＜
ja-JP
0123.456
1970/01/02 15:00:00

en-US
0123.456
1/2/1970 3:00:00 PM

vi-VN
0123,456
02/01/1970 3:00:00 CH

fr-FR
0123,456
02/01/1970 15:00:00

ていうか数値にしても日付にしても（結果的に？）計算機環境への適応性で言うと日本の形式優秀では感＞＜（優秀というか合理的？＞＜）

csv怖い＞＜；（この問題までは知らなかったけど、トラブル起こしやすいと思ってたのでcsv嫌ってtsv好んでた＞＜）

つまり、csvで数値を保存する時にも " " で囲うの必須で（数値なら要らないと今まで思ってた＞＜；）、
csvから数値を読む場合は、SIに従うならば（？）、『 . 』も『 , 』もどちらも小数点であるとみなさなければならないっぽい＞＜

ていうかベトナムがというかフランスの影響が強いエリアがだいたいフランス式つまり『 , 』方式で結構広いエリアで、つまりダメじゃん＞＜

fr-FR
0123,456

oh!><;

小数点 - Wikipedia https://ja.wikipedia.org/wiki/%E5%B0%8F%E6%95%B0%E7%82%B9
"国際単位系(SI)では小数点について、イギリス式でもフランス式でも、どちらでもよいと規定している。"

ISOにあわせればよくね？＞＜
って思ったんだけど、ISO 80000-1も前身のISO 31-0も本文の小数点が『 , 』になってる感・・・・＞＜；

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

ていうかオレンジはCSV使いそうな場面は基本的にTSV使ってる＞＜

TSV（タブ区切り形式）が大好きなのでその他に入れた＞＜

paizaioにベトナムロケールでカンマ怖いのデモ書いた＞＜；
https://paiza.io/projects/1gHTk7HzwOwqqAedKml0aA

知らんかった「カスタム数値形式ならだいじょうぶだよね＞＜」と思い込んでたし、つまり、オレンジがC# で今まで書いてきたやつだいたいベトナム語版Windowsではちゃんと動かない？＞＜；

本題のベトナムロケールでも試した＞＜；
vi-VN
0123,456
ちゃんと , になっちゃった！！！＞＜；
C# で数値を文字列にしたいときは必ず明示的にCultureInfo.InvariantCultureをつけないと危険！！！＞＜；
（当たり前だけど、つければちゃんとベトナムロケールでも0123.456になった＞＜）

CultureInfo culture = CultureInfo.GetCultureInfo("da-DK");
CultureInfo.DefaultThreadCurrentCulture = culture;
CultureInfo.DefaultThreadCurrentUICulture = culture;
ってして、
double d = 123.456;
Console.WriteLine(Thread.CurrentThread.CurrentUICulture);
Console.WriteLine(d.ToString("0000.000"));
ってしたら
da-DK
0123,456
って出た！＞＜；

自己解決しました！＞＜；
c# - How set a culture for entire winform application - Stack Overflow https://stackoverflow.com/questions/51602944/how-set-a-culture-for-entire-winform-application

ていうか、.NETなアプリ作るときにアプリ全体にシステムの情報無視して特定のロケール情報上書きするって出来ないのかな？＞＜
Application.CurrentCultureをApplication.Runの直前で書き換えてもメインスレッドのCurrentCultureがja-JPのまま・・・＞＜

https://docs.microsoft.com/ja-jp/dotnet/standard/base-types/custom-numeric-format-strings#SpecifierPt

CultureInfo.InvariantCulture忘れず必ずつけないと危険！？＞＜；

https://docs.microsoft.com/ja-jp/dotnet/standard/base-types/custom-numeric-format-strings#SpecifierPt
' "." カスタム指定子
"." カスタム書式指定子は、ローカライズされた小数点を結果の文字列に挿入します。'

・・・・・・＞＜；

よく考えてみると、このパターンだと区切り文字列とかもアレでダメパターン？＞＜；

ていうか、機械的に読む可能性がある数値の文字列としての出力には、ちゃんと1文字ずつ指定する方の書式指定使わないとダメじゃん感＞＜ 日時とかもそう＞＜

豊崎由美さんと『けんご』さんの諍いと「書評」についての雑感 - いつか電池がきれるまで https://fujipon.hatenablog.com/entry/2021/12/14/084500

居た＞＜

今週のはてなブログランキング〔2021年12月第3週〕 - 週刊はてなブログ https://blog.hatenablog.com/entry/2021/12/20/150000

このアカウントは、notestockで公開設定になっていません。

このミスと謝罪に関する日米の文化の違いの話関連で、オレンジ的にひとつ謎な事例が、ツイッターの日本の拠点に居るらしい土下座要員ってどこの誰の発想で用意したんだろう？＞＜；　って事かも＞＜
アメリカの文化ではとにかく謝って済ますなんてしても全く通用しないらしいので、日本側の発想で用意したのか、それともアメリカ側で「なんか日本の文化だと理由説明しなくても土下座すれば済むらしいデス！」「マジで！？」ってなったのか？＞＜；

他の国はどうなのかわかんないけど、日本とアメリカの比較だと、日本は理由を言わない謝罪の文化で、アメリカは謝罪ほぼしないけど理由を言いまくるし理由聞きまくる文化で、
検証のための情報が出やすいのはアメリカだけど、一方で責任超細分化な文化なので改善策の実行があまり為されないらしい＞＜；(「だって俺は悪くないし」で改善策が行き渡らないし、失敗に関する情報の共有も基本的に行われない)
日本の文化だと連帯責任や組織の責任を所属する個人も負う文化で、組織や組織に所属する構成員への個人攻撃にも向かいやすいけど、そのネチネチのおかげで改善してるかの監視が行われ、改善しないわけにいかない状況に追い込まれ改善される＞＜
けど、謝罪偏重が強いのでアメリカと比べると調査が苦手かも＞＜

謝罪も全く無意味では無いけど単に謝るのは人間関係どうたらだけの話になっちゃう＞＜
そうではなく謝罪は問題の検証と改善策の実行意思の確認として機能させるのならば意味がある＞＜
「こういう原因でこういう事態になりこういう結果に至ったので、次にこうなった時にはこうならないようにこのような対応をします」が謝罪での重要な部分で、その上で「ごめんなさい」ならば「改善しそう＞＜」ってなるかも＞＜

このアカウントは、notestockで公開設定になっていません。

ていうか検証と改善を拒否するのがダメかも感＞＜
ミスに対して謝罪で済まそうとするのは、ミスの個人攻撃の裏側というか、ミスした側がわざわざミスを個人の問題に矮小化してるのと同じだよね＞＜

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

WTA、彭帥の性的暴行否定映像は「懸念解消しない」　写真1枚　国際ニュース：AFPBB News https://www.afpbb.com/articles/-/3381685

選手派遣も含めた完全ボイコットしてもおkな理由が出て来た＞＜

彭帥、性的暴行の告発否定 安全懸念も「自由」と主張　写真2枚　国際ニュース：AFPBB News https://www.afpbb.com/articles/-/3381677