Vista - bug in string<->datetime conversion?

Hi

I have strange (and quite anying) problem with conversion between string
and datetime. The problem lies in the difference between US (mm/dd/yyyy)
and european (dd/mm/yyyy) date notation standards. When converting from
{string] to [datetime] i get different results when using type casting
and the -as operator. The ype cast method seems to expect US notation
where the -as operator expects European notation. The other way around
([datetime] to [string]) always produces a string with US notation.

I have tried these on 1 XP and 1 Win2003Std and with the same result.
The Windows is US version with regional settings set to Danish.

It seems obvious that these methods at least in pair should work with
the same notation.

Does any one know of a fix or maybe a workaround (besides custom
formatting)?


Example results:
PS > [string] (get-date)
11/23/2007 14:51:05

PS > (get-date) -as [string]
11/23/2007 14:51:22

PS > "11/23/2007 14:51:22" -as [datetime]
$null

PS > [datetime] "11/23/2007 14:51:22"
23. november 2007 14:51:22

PS > "23/11/2007 14:51:22" -as [datetime]
23. november 2007 14:51:22

regards
Nikolaj Bech

IMHO it's a bug in PowerShell type conversion. [string] to [datetime]
converter simply do not use current thread CultureInfo, while [datetime] to
[string] do use.

Workaround:
$d="26.11.2007"
[datetime]::Parse($d, [System.Threading.Thread]::CurrentThread.CurrentCulture)

"Nikolaj Bech" wrote:

This is an explicit design goal.

PowerShell treats "[DateTime] '11/26/2007'" (a direct string cast) like a
language feature along the lines of:

[Double] 10.5

Many cultures represent dates and numbers differently, but direct language
features should always be unambiguous. Otherwise, scripts that run
successfully on one person's machine are unlikely to work on a machine from
any other culture.

--
Lee Holmes [MSFT]
Windows PowerShell Development
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.


"vsplus" <vsplus@xxxxxx> wrote in message
news:20993D4E-24CD-4AA4-A695-CA6A76822F93@xxxxxx

The theme "bug or feature" may be discussed forever. There is a contradiction
in design goals and your choice isn't right IMHO.

Please look at this screenshot:

PS > [datetime]::Now -lt "27.11.2007 10:10:00"
The '-lt' operator failed: Could not compare "27.11.2007 10:10:11" to
"27.11.2007 10:10:00". Error: "Cannot convert val
ue "27.11.2007 10:10:00" to type "System.DateTime". Error: "Строка не
ра�познана как дей�твительное значение DateTime."
".
At line:1 char:20
+ [datetime]::Now -lt <<<< "27.11.2007 10:10:00"

When you look at "Could not compare "27.11.2007 10:10:11" to "27.11.2007
10:10:00"." what is your first reaction?

If your design goal was to provide intuitively acceptable command line for
mid-level sysadmins - you have failed.

If your design goal was to provide command line to order scripts for
everyday needs (with date constants I mean) strictly from USA scripters - you
win.


"Lee Holmes [MSFT]" wrote:

I agree -- this error message is confusing. Could you please file a bug on
the Connect Website?

As for the design goals, I probably could have explained myself better.

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.

--
Lee Holmes [MSFT]
Windows PowerShell Development
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.


"vsplus" <vsplus@xxxxxx> wrote in message
news:A5F2891D-3FDC-427D-90EE-89AA115111CB@xxxxxx