我愚蠢的是，我无法独自一人弄清楚这一点。
我有来自Carbonblack API的日期，例如2022-02-15-172040，它在UTC中
[dateTime] type cast cast如果我删除字符串的秒部分
PS M:\Scripts> [datetime]"2022-02-15-1720"
Tuesday, February 15, 2022 12:20:00 PM
，则可以 正常工作它“知道”是一个UTC字符串。当然，这是正确的，但我预计时间部分下午5:20。我想要该日期的几秒钟，所以我完全去解析了，因为据我所知，
PS M:\Scripts> [datetime]::ParseExact("2022-02-15-172040", "yyyy-MM-dd-HHmmss" ,[Globalization.CultureInfo]::CurrentUICulture)
Tuesday, February 15, 2022 5:20:40 PM
这是我所期望的时间，而是不正确的时间。
为什么 [dateTime] 在我不期望的情况下工作，而我需要对字符串或静态方法做些什么才能将其视为用最小操作的UTC字符串？
I feel silly that I cannot figure this one out on my own.
I have dates coming from the CarbonBlack API e.g. 2022-02-15-172040 which are in UTC
The [datetime] type cast works fine if I remove the seconds portion of the string
PS M:\Scripts> [datetime]"2022-02-15-1720"
Tuesday, February 15, 2022 12:20:00 PM
I don't understand how it "knows" that is a UTC string. It is correct of course but I expected 5:20pm for the time portion. I wanted the seconds for the date so I went to parse exact as this doesn't match any format strings as far as I know
PS M:\Scripts> [datetime]::ParseExact("2022-02-15-172040", "yyyy-MM-dd-HHmmss" ,[Globalization.CultureInfo]::CurrentUICulture)
Tuesday, February 15, 2022 5:20:40 PM
Which is the time I expected but the incorrect time.
Why is the [datetime] working when I wouldn't expect it to and what do I need to do to the string or static method call for it to treat that as a UTC string with minimal manipulation?
发布评论
评论（1）
这是因为
产生' local
'
结果应在 utc 中，使用：
相反
，因此，如果您考虑字符串中的日期代表 utc （通用时间），并且您希望结果结果要进来
本地时间，您需要这样做：
在这里，
parseexact（）将字符串视为UTC，并输出日期转换为本地时间（
.kind- ＆gt;'local'），这与给出的输出完全相同：此处，
.kind- ＆gt;＆gt; 'local'`如果您希望产生的日期在UTC中，则需要使用
.touniversaltime（）再次将其转换回它，棘手的部分是使用
parseexact（）没有解析没有的字符串时指示它是本地或UTC，例如此处的示例字符串，始终以其
.kind属性设置为 未指定的DateTime对象。感谢
如果确实给它第三个参数，请告诉它应该使用的是什么时区（'ash eLocal'或'pabusuniversal'），则结果的dateTime对象将
始终将其
.kind属性设置为 local ，并且如果您给出了pauseuniversal作为参数，则结果将转换为本地时间。This is because
yields 'Local', while
returns 'Unspecified'
If you want the result to handle the string as being Local time and then the result should be in UTC, use:
or
Going the other way around, so if you regard the date in the string represents UTC (Universal Time), and you want the result to be in
Local time , you need to do this:
Here,
ParseExact()treats the string as UTC and outputs a date converted to Local time(
.Kind--> 'Local'), which is the exact same output aswould give: also here,
.Kind--> 'Local'`If then you want the resulting date to be in UTC, you need to convert it back again with
.ToUniversalTime()The tricky part is that using
ParseExact()without the third parameter ('AssumeLocal' or 'AssumeUniversal') when parsing a string that has noindication of it being Local or UTC like the example strings here, is always returning a datetime object with its
.Kindproperty set to Unspecified.Thanks to mklement0's comment,
in PowerShell (Core) 7+, strings like in the example are no longer recognized and should have a TimeZone indication like '2022-02-15 17:20Z'. ('Z' --> Zulu (UTC) Time)
If you do give it the third parameter, telling it what timezone it should use ('AssumeLocal' or 'AssumeUniversal'), the resulting datetime object will
always have its
.Kindproperty set to Local and the result will be converted to local time in case you have givenAssumeUniversalas parameter.