Skip to content
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

PS 7.2.0 breaks Write-Calendar.ps1 #1

Open
JoeSalmeri opened this issue Dec 6, 2021 · 3 comments
Open

PS 7.2.0 breaks Write-Calendar.ps1 #1

JoeSalmeri opened this issue Dec 6, 2021 · 3 comments

Comments

@JoeSalmeri
Copy link

JoeSalmeri commented Dec 6, 2021

@krispharper

Not sure if you have upgraded to PS 7.2.0 yet but it has a code breaking change which affects your Write-Calendar.ps1 script.

The code breaking change has to do with when you call Get-Date -Uformat %u

Prior to PS 7.2.0 when the date was a Sunday then Get-Date -Uformat %u returned 0 and it used values of ( 0 -6 for Sunday - Saturday).

PS 7.2.0 now returns 7 for Sunday ( and has values 1-7 for Monday-Sunday).

MS did not even consistently make the change or update all the documentation.

For example:

[System.Enum]::getvalues([type][System.DayOfWeek]) | ForEach-Object { echo "$_ $($_.value__)" }

Still has values of 0-6 for Sunday - Saturday and returns 0 for Sunday

Here are some other examples between PS 7.1.5 and PS 7.2.0 but it should be noted that the PS 7.1.5 behavior is how it has been all the way back to Windows PowerShell 5.1. Also the issue occurs on both Windows PS 7.2.0 and Linux PS 7.2.0

ps 7.1.5

    Get-Date 05/01/2022 -uformat %u           # returns 0              - Correct
    (Get-Date 05/01/2022).DayOfWeek         # returns Sunday    - Correct
    [int](Get-Date 05/01/2022).DayOfWeek   # returns 0              - Correct


ps 7.2.0

    Get-Date 05/01/2022 -uformat %u            # returns 7              - Wrong
    (Get-Date 05/01/2022).DayOfWeek          # returns Sunday    - Correct
    [int](Get-Date 05/01/2022).DayOfWeek    # returns 0              - Correct

You use this the value to determine offsets when you print the month and year calendars.

I reported this bug to MS and they claim the change was on purpose and I have been discussing with them because in addition to breaking this code it creates issues for anything else that used Get-Date -uFormat %u and it creates an inconsistency in PS because list type items are zero based and not 1 based.

You can view my bug here as well as the discussion

PowerShell/PowerShell#16562

Hope that is helpful too you.

Joe

  • Updated to fix the URL I first posted which was wrong
@brianary
Copy link

brianary commented Apr 4, 2023

Get-Date 05/01/2022 -UFormat %u should return 7, because the %u format is meant to support ISO8601 week dates, which define the days of the week as 1 through 7. See also the man page for date, which is what -UFormat is emulating.

@JoeSalmeri
Copy link
Author

JoeSalmeri commented Apr 4, 2023

Get-Date 05/01/2022 -UFormat %u should return `7

You kind of missed the KEY point. It is NOT about about what -UFormat %u"should" return.

In PS version PRIOR versions to 7.2,, -UFormat %u returned the day of the week ( 0 to 6 ) with Sunday=0 to Saturday=6

In PS version 7.2 this CHANGED and -UFormat %u returned the day of the week ( 1 to 7 ) with Monday=1 to Sunday=7.

They changed the values the function returns!

Therefore since the return values changed ANY existing code ( like this program ) that expects Sunday to be 0 was broken because now Sunday=7.

It is NOT about what it "should" return, it is about the fact that they made a change which broke existing code.

Considering the number of times that I have reported bugs to MS and the answer was we cannot fix a bug because it might break existing code which depended on that bug/behavior,, it is quite frustrating when they go and make changes which break existing code that depended on it!

This program uses the day of the week number to calculate offsets for where to display the calendar days so when Sunday started returning 7 instead of 0 like it used to that means the calendars were screwed up since that was used to calculate the offsets.

Seems pretty straightforward to me, a code breaking change was made.

@brianary
Copy link

brianary commented Apr 7, 2023

I was responding to the Wrong comment above, which is inaccurate.

I've definitely been frustrated by Microsoft not fixing things due to inertia, but that's largely the Office, browser, and SQL teams. Something with a much smaller and more technical user base is less likely to be paralyzed by it, especially for something where there is another (more correct) way to get the original behavior. I'm more in favor of fixing bugs, personally, but I understand the annoyance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants