16

昨日CSVを読み込もうとしたとき、PowerShellはを使用するときに常に米国の日付形式を想定しているように見えることに気付きました[datetime]"date"。

私の地域の設定はすべて正しく、[DateTime]::Parse("date")英国の日付形式（dd / mm / yyyy）を使用しています。

これはバグですか、それとも意図的な決定ですか？意図的な決定の場合、これはどこかに文書化されていますか？

PS D:\> [DateTime]"12/10/2012"
10 December 2012 00:00:00

PS D:\> [DateTime]::Parse("12/10/2012")
12 October 2012 00:00:00

（注：米国のマシンでは、これらのオブジェクトは同じになると思いますが、英国の私のマシンではそうではありません）。

注：フォーマットを変更したくない（外部ソースからのファイルです）、出力で日付をフォーマットしたくない、使用できることはわかっています[DateTime]::Parse()。問題は?:-)で終わるビットです

4

2 に答える 2

16

それは意図的な決定です。文字列をにキャストするときDateTimeは、braindeadUS形式またはISO8601のいずれかを使用でき[datetime]'2012-10-12'ます。これは問題なく機能し、読みやすくなっています。

これが制限されている理由は、少なくともリテラルと準リテラル（キャストされた文字列など）については、スクリプトが現在のカルチャに依存してはならないためです。これは堅牢なバッチファイルを作成する際の大きな問題であり、PowerShellで同じ問題が発生することは望ましくありません。

Lee Holmesには、 MSのPowerShellチームに所属していたため、半公式と見なすことができる説明があります。

微妙な国際化の問題がスクリプトに現れるのを防ぐために、PowerShellは[DateTime] '11/26/2007'（日付定数）を言語機能のように扱います-それが[Double] 10.5（数値定数）と同じように扱います。すべての文化が小数点を分数の区切り文字として使用するわけではありませんが、プログラミング言語はそれ。すべてのカルチャがen-USDateTime形式を使用しているわけではないため、それらのカルチャでソフトウェアを実行することの影響を考慮しないと、何百万もの国際化バグが発生します。

Leeが言及するのを忘れているのは、私が以前に書いたことです。はるかに賢明なISO8601形式も同様に機能します。

残念ながら、PowerShellのドキュメントと言語仕様（v2）のどちらにもこれに関するドキュメントはありません。ただし、これがバグであることを示す証拠はほとんどありません。

于 2013-01-16T13:00:10.353 に答える
0

必要に応じて、単一のコマンドのカルチャを強制できます。

PS C:\> [System.Threading.Thread]::CurrentThread.CurrentUICulture = "en-US" ; [System.Threading.Thread]::CurrentThread.CurrentCulture = "en-US"; [DateTime]::Parse("12/10/2012")

Monday, December 10, 2012 12:00:00 AM

PS C:\> [System.Threading.Thread]::CurrentThread.CurrentUICulture = "en-GB" ; [System.Threading.Thread]::CurrentThread.CurrentCulture = "en-GB"; [DateTime]::Parse("12/10/2012")

12 October 2012 00:00:00
于 2020-08-26T22:17:52.520 に答える