为什么 PowerShell 在转换为 DateTime 时总是使用美国文化? [英] Why does PowerShell always use US culture when casting to DateTime?

查看:11
本文介绍了为什么 PowerShell 在转换为 DateTime 时总是使用美国文化?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

昨天尝试读取 CSV 时,我注意到 PowerShell 在使用 [datetime]"date" 时似乎总是采用美国日期格式.

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

我的区域设置都正确[DateTime]::Parse("date")使用英国日期格式(dd/mm/yyyy).

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).

注意:我不想更改格式(它是来自外部源的文件),我不想在输出中格式化日期,我知道我可以使用 [DateTime]::Parse().问题是以 ? 结尾的位 :-)

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 ? :-)

推荐答案

这是一个深思熟虑的决定.将字符串转换为 DateTime 时,您可以使用 Braindead US 格式 ISO 8601 – [datetime]'2012-10-12'工作得很好,阅读起来也更好.

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.

限制和限制的原因是脚本不应该依赖于当前的文化,至少对于文字和准文字(如强制转换的字符串).这是编写健壮的批处理文件时的一个主要问题,您当然不希望在 PowerShell 中出现同样的问题.

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 有一个解释,它可以被认为是半官方的,因为他现在/曾经在 MS 的 PowerShell 团队中:

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

为防止在您的脚本中出现微妙的国际化问题,PowerShell 将 [DateTime] '11/26/2007'(一个日期常量)视为一种语言功能 - 就像 一样[双] 10.5(一个数字常量.)并非所有文化都使用小数点作为分数分隔符,但编程语言对其进行标准化.并非所有文化都使用 en-US DateTime 格式,当人们不考虑在这些文化中运行他们的软件的影响时,会导致数百万国际化错误.

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.

Lee 忘记提及的是我之前写的,更合理的 ISO 8601 格式也可以工作.

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

遗憾的是,PowerShell 文档或语言规范 (v2) 中都没有这方面的文档.但是,几乎没有证据表明这是一个错误.

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.

这篇关于为什么 PowerShell 在转换为 DateTime 时总是使用美国文化?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆