@webelaine,
Thank you for raising this bug. You have raised a real issue for month end and differences between time zones. Had you been in a time zone in advance of UTC, then the issue would arise in the first hours of the new month.

Since the permalink is giving parameters to do a look up on post_date, then the month and year have to match that of the post_date, not post_date_gmt. The field in the database is datetime. This does not contain any timezone element and it will be written as the number in the writer's timezone. In this case, 31 october at 21:00:00. Thus we need 2022/10 in the permalink.

However, I am concerned about the processing of this and the next line.

$timestamp = strtotime( $document->post_date );
This will take the datetime of the post date 2022-10-31 21:00:00 and make it the timestamp 2022-10-31 21:00:00 CST.
It is the same but with a time zone because that is the timezone from which it was published.
gmdate( 'Y', $timestamp ) . '/' . gmdate( 'm', $timestamp )
The next line takes that timestamp and applies gmdate to it. This expresses the timestamp in UTC - which is 2022/11/01 02:00:00 UTC So I am actually somewhat surprised that this now worked.

FWIW, my machine is normally set to Paris time. At 21:39, I created a post. In the database post_date is set as 21:39 and post_date_gmt is 20:39. I then set the WP instance to Chicago time. At 21:41, I created a new post. post_date was set to 14:41 and post_date_gmt to 20:41.

I think that the field post_date - a string valiable - already contains the required data - and the timezone conversions just confuses things.. Certainly I have spent a considerable time trying to understand the various timestamp operations.

I would like to propose for your consideration this replacement code:
` // build yyyy/mm directly from the post_date string.
$yr_mth = str_replace( '-', '/', substr( $document->post_date, 0, 7 ) );

		$link  = untrailingslashit( home_url() ) . '/' . $this->document_slug() . '/' . $yr_mth . '/';`

This avoids using timezone-related functions completely and extracts the required data directly.

Kind Regards,
Neil James

@NeilWJames - you raise an excellent point. I agree that pulling the month and year directly from the post_date makes more sense than converting to a datetime and swapping timezones. I have pushed a new commit using this suggestion. Thanks for your help!