-
Notifications
You must be signed in to change notification settings - Fork 8.1k
WIP: Fix Get-Date -UFormat %V week number output
#4508
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
iSazonov
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@timparkinson Thanks for your contribution!
Could you please review all uformat patterns - it seems we should fix all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe we shouldn't create new object.
System.Threading.Thread.CurrentThread.CurrentCulture.Calendar
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't believe using the CurrentCulture is appropriate in this case, because ISO 8601 is Gregorian calendar based and CurrentCulture could be set to a different calendar.
In any case further tests based on the table at https://en.wikipedia.org/wiki/ISO_week_date#Relation_with_the_Gregorian_calendar shows that my initial stab at this was incorrect, because the GetWeekOfYear does not produce the ISO 8601 output for all cases. I'll take a bit of a harder stare at this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe we should follow CoreFX and should be CurrentCulture based not ISO based for all culture.
/cc @SteveL-MSFT
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with @iSazonov that in general, we should be using CurrentCulture. Not an expert by any means on this topic, but looking at the Wikipedia page, it seems we should implement the formula they have there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CoreCLR already implemented this in GregorianCalendar(...)
We can use the implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The tests may fail if current locale is not English. So we shouldn't use explicit constants - please evaluate them.
$a=Get-Culture
$a.Calendar
...
|
@timparkinson Could you please continue? |
|
@iSazonov yes, I'm happy to continue looking at this, but I haven't had time over the last week. I may be able to spend a bit of time this weekend. I did start looking at the other UFormats and there are definitely others that don't match the output from the Linux date command. Would you prefer me to address them as one PR or create separate issues for each? |
|
If you are limited in time you can split the work on some PRs - describe all points in one Issue and fix step by step. |
|
@iSazonov OK, I'll raise another issue detailing all the deviations from Linux behaviour in UFormat and then I'll look to fix step by step as you suggest. I have a mini vacation after today, and will be without computer/internet - I'll hopefully be able to get to it next week. |
|
/cc @SteveL-MSFT Changing |
|
Backchanneled with @SteveL-MSFT, I'm good with these changes. |
|
@PowerShell/powershell-committee discussed this briefly and agree the change makes sense |
|
@timparkinson Please rebase. |
|
As previously discussed, I intend to raise another issue to document all the UFormat divergences since there are several. Since this PR is incorrect anyway, I guess I should simply close it? |
|
It would be right to open the new Issue first and then decide on the fate of that PR. Currently you can rebase: |
Fix PowerShell#4264 makes week number handling compliant with ISO-8601.
This reverts commit a5886cd5e419e07b884815f740e08b3c69513179. Solution was incorrect and needs a lot more work.
Fix PowerShell#4264 makes week number handling compliant with ISO-8601.
This reverts commit a5886cd5e419e07b884815f740e08b3c69513179. Solution was incorrect and needs a lot more work.
Fix PowerShell#4264 makes week number handling compliant with ISO-8601.
This reverts commit a5886cd5e419e07b884815f740e08b3c69513179. Solution was incorrect and needs a lot more work.
Fix PowerShell#4264 makes week number handling compliant with ISO-8601.
This reverts commit a5886cd5e419e07b884815f740e08b3c69513179. Solution was incorrect and needs a lot more work.
|
This PR appears empty. Can it be closed? |
%V week number output
%V week number output%V week number output
|
Closing as well out of date. |
PR Summary
Fix #4264 makes week number output compliant with ISO-8601.
PR Checklist
.h,.cpp,.cs,.ps1and.psm1files have the correct copyright headerWIP:to the beginning of the title and remove the prefix when the PR is ready.[feature]if the change is significant or affects feature tests