Correct %c format in Get-Date -UFormat #4769
Conversation
Add leading zero in day
iSazonov
requested review from
JamesWTruher,
PaulHigin and
dantraMSFT
as code owners
|
@timparkinson @mklement0 Could you please review too? |
| sb.Append("{0:ddd} {0:MMM} "); | ||
| sb.Append(StringUtil.Format("{0,2} ", dateTime.Day)); | ||
| sb.Append("{0:HH}:{0:mm}:{0:ss} {0:yyyy}"); | ||
| sb.Append("{0:ddd} {0:MMM} {0:dd} {0:HH}:{0:mm}:{0:ss} {0:yyyy}"); |
There was a problem hiding this comment.
Apparently, there are platform differences (not specific to the date utility implementation): on macOS 10.12.6 I get space-padded representation (e.g., <space>7), on Ubuntu 16.04 I get the 0-padded representation (e.g., 07).
There was a problem hiding this comment.
On WSL I get space too. And it seems it can be culture-depended (see related Issue). I think we can not be full-compliant with Unix here. So we should follow "common" rule.
There was a problem hiding this comment.
we should follow "common" rule.
I'm asking innocently: what do you mean by that?
I just checked the spec for the POSIX date utility, and the definition of %c is (a) definitely locale-(culture)-specific and (b) pretty open-ended:
%c
Locale's appropriate date and time representation.
...
The %x and %c conversion specifications, however, are intended for local representation; these may be based on a different, non-Gregorian calendar.
There was a problem hiding this comment.
Sorry, I meant that "common" - used in most Unix clones.
Thank you for confirmation this is a locale-(culture)-specific. The problem may lie in the fact that we are forced to rely on CoreFX rather than Unix locales. I think that's a good compromise because our goal is to emulate Unix-like format. If we want more we should address this in CoreFX.
|
Moved to #4805 |
4 participants
Related #4750.
Add leading zero: now day of the month is from 01 through 31.
Before fix:
After the fix: