Why does PowerShell always use US culture when cas

Question

When trying to read a CSV yesterday, I noticed that PowerShell seems to always assume US date format when using [datetime]"date".

My regional settings are all correct, and [DateTime]::Parse("date") uses the UK date format (dd/mm/yyyy).

Is this a bug, or a deliberate decision? If a deliberate decision, is this documented anywhere?

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

(Note: on a US machine, I expect these objects will be the same, but not so here on my machines in the UK).

Note: I don't want to change the format (it's a file from an external source), I don't want to format dates in output, I know I can use [DateTime]::Parse(). The question is the bit that ends with a ? :-)

Answer 1

It is a deliberate decision. When casting a string to a DateTime you can use either the braindead US format or ISO 8601 – [datetime]'2012-10-12' works just fine and is much nicer to read.

The reason that this is limited and restricted is that scripts should not have a dependency on the current culture, at least for literals and quasi-literals (like casted strings). This is a major problem in writing robust batch files and you certainly don't want the same problems in PowerShell.

Lee Holmes has an explanation, which could be considered semi-official, as he is/was on the PowerShell team at MS:

To prevent subtle internationalization issues from popping into your scripts, PowerShell treats [DateTime] '11/26/2007' (a date constant) like a language feature – just as it does [Double] 10.5 (a numeric constant.) Not all cultures use the decimal point as the fractions separator, but programming languages standardize on it. Not all cultures use the en-US DateTime format, resulting in millions of internationalization bugs when people don’t consider the impact of having their software run in those cultures.

What Lee forgets to mention is what I wrote before, that the much more sensible ISO 8601 format works as well.

No documentation of this exists in either the PowerShell documentation or the Language Specification (v2), sadly. However, there is very little evidence that points to this being a bug.