Fix [DateTime] for proper international use
Votes from Connect: 21
Original Date Submitted: 12/22/2014 2:44:28 AM
Handle: Chris J Warwick
Site Name: PowerShell
Feedback ID: 1062130
Frequency: Always Happens
Regression: Yes, this happens in all previous versions
The [DateTime] type accelerator assumes US format dates for short date formats. As a user outside of the US, the date ‘1/2/2014’ would be the 1st February 2014 for me - but I assume not everyone would see it that way. This does not vary depending on your locale.
I often see people struggling with this and even to this day, date formatting is clearly not well understood (e.g. a bug in V5 beta for Find-Module documented here http://blogs.msmvps.com/richardsiddaway/2014/12/21/delivering-powershell-code-with-the-november-preview/ reveals the issue).
[DateTime] may honour culture in some senses, but it assumes short format date strings (such as those found in many log files for example) are in US format (i.e. mm/dd/yy). The argument for using a fixed format (spurious in my opinion) being that this was necessary for portability. But why US format was chosen remains a mystery.
I think [DateTime] is broken because:
- [DateTime] should, like Get-Date, respect culture, and
- If a fixed format date must be used it should be in an internationally agreed format (ISO 8601/RFC3339).
This could be fixed by introducing two new accelerators:
…and subsequently deprecating [DateTime]
Product Studio item created by Connect Synchronizer due to creation of feedback ID 1062130 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1062130).
PS:> Get-Culture | Format-List Name, DisplayName, EnglishName
Name : en-GB
DisplayName : English (United Kingdom)
EnglishName : English (United Kingdom)
PS:> Get-Culture | Select -Expand DateTimeFormat | Select ShortDatePattern
21 December 2014 00:00:00
Cannot convert value "21/12/2014" to type "System.DateTime". Error: "String was not recognized as a valid DateTime."
At line:1 char:1
+ CategoryInfo : InvalidArgument: (:) , RuntimeException
+ FullyQualifiedErrorId : InvalidCastParseTargetInvocationWithFormatProvider
[DateTime] should respect Cultural formatting (or proper, sensible, alternatives should be provided along with copious documentation).
Internal BugId: 13155
Alex Karpus commented
Here is a repro,
> Set-Culture "en-GB" # you may have to start a new PS session for culture to take effect
> ([datetime] "06/08/2018").ToShortDateString() # expecting 06/08/2018
> ("06/08/2018" -as [datetime]).ToShortDateString() # expecting 06/08/2018
For some reason the current culture's format is honored when casting using the -as operator, but not when performing an explicit cast.