PS 7.2.0 breaks Write-Calendar.ps1

[JoeSalmeri]

@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]

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]

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]

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.