One thing that sometimes comes as a surprise (most recently as a comment on the PowerShell blog) is that DateTime casts are always parsed in the en-US DateTime format:

Casting to a DateTime object doesn’t respect the current culture of the thread. For example:

> [Threading.Thread]::CurrentThread.CurrentCulture

LCID  Name

-—  —-

2057  en-GB

> [DateTime] “01/02/03”

02 January 2003

> # Note US date interpretation.

This is an explicit design goal.

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.

Imagine a random script that you find on the internet. It was probably written on a system that uses a different culture than you or I. For the script to run correctly our machines, the author needs to write in a culturally-sensitive way:

1. The approach taken by traditional software development for internationalization:

$date = New-Object System.DateTime 2007,11,27,17,56,00

or (an imagined PowerShell syntax)

$date = [DateTime->pt-PT] “terça-feira, 27 de Novembro de 2007 9:34:50”

2. An approach that assumes a specific culture, which is the approach PowerShell takes:

$date = [DateTime] “11/27/2007 5:56:00 pm”

Approach #2 is much more user-friendly, as it minimizes what you need to remember. In approach #1, you always need to remember to specify your locale when you create the DateTime. In approach #2, you always need to remember to use the en-US format (as you already do when writing floating-point constants.)

The additional benefit of assuming a specific culture is that you are protected from people that do NOT write the script in a culturally-sensitive way. While some advanced scripters might be able to understand approach #1, most scripters (and even professional software developers) do not. History has shown us that software not explicitly TESTED for internationalization fails spectacularly. I don’t mean “written for international markets,” I mean TESTED for them.

When an admin bashes together a script because their hair is on fire, and then wants to share it later – testing for other regions is not high on the list of things to do.