DateTimePicker in the post editor does not show posts that are published on midnight of first day of month

[butesa]

In the post editor, there is a date/time picker to select the publication time. Day with a publication are marked with a blue dot.

The blue dot is missing if the post is scheduled for midnight of the first day of month.

The SQL query that is executed by the REST API contains this condition: wp_posts.post_date < '2025-08-31 23:59:59' AND wp_posts.post_date > '2025-08-01 00:00:00'

[Presskopp]

I'm unable to reproduce. Can you please explain more the how to? I'm setting a post to be published 00:00 at August, 1st and I'm getting the blue dot.

[butesa]

I just created two posts (scheduled for 2025-08-01 00:00 and 2025-08-02 00:00) and then started to create a third post. When I select the publish date, there is a dot for 2025-08-02, but not for 2025-08-01.

If I change the date of the first post to 2025-08-01 00:01, the dot appears.

I tested with Firefox 139.0.4, WordPress 6.8.1 and all WordPress plugins disabled.

In the Firefox Developer Tools Network Analysis I see this:
Request
GET ​http://localhost/code/momentmal/wp-json/wp/v2/posts?context=edit&status=publish,future&after=2025-07-31T22:00:00.000Z&before=2025-08-31T21:59:59.999Z&exclude[0]=375&per_page=100&_fields=id,date&_locale=user

Response
[{"id":365,"date":"2025-08-02T00:00:00"}]

[butesa]

I can make the dot appear with this change:

--- a/wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php
+++ b/wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php
@@ -292,6 +292,7 @@
 			$args['date_query'][] = array(
 				'after'  => $request['after'],
 				'column' => 'post_date',
+				'inclusive' => true,
 			);
 		}

[Presskopp]

I am now able to reproduce the issue. The behaviour depends on the set time zone. If set to 'Berlin' for example the dot will not be there, if set to 'UTC' it will be there.

After some testing I can confirm your patch is resolving the issue.

[websiteredev]

Reproduction Report

This report validates that the issue can be reproduced.

Environment

• OS: Windows 10 Build 19045
• Web Server: PHP.wasm
• PHP: 8.0.30
• WordPress: 6.8.1
• Browser: Chrome Version 137
• Theme: Twenty Twenty-Five
• Active Plugins:
  • None - Fresh Install

Steps

1. Create a post scheduled for midnight (12:00AM) on August 1st, 2025.
2. Create a post scheduled for midnight (12:00AM0 on August 2nd, 2025.
3. Go to create a new post and navigate to scheduling date/time selection menu.
4. Confirm that a blue dot is placed under August 2nd to show a post scheduled for this date, but no corresponding dot is placed under August 1st.

Actual Results

• ✅ Error condition occurs (reproduced).

[websiteredev]

Patch Test Report

This report validates that the indicated patch addresses the issue.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/9201

Environment

• OS: Windows 10 Build 19045
• Web Server: PHP.wasm
• PHP: 7.4.31
• WordPress: 6.9-alpha-20250703.171513
• Browser: Chrome Version 137
• Theme: Twenty Twenty-Five 1.2
• Active Plugins:
  • None

Steps

1. Create a post scheduled for midnight (12:00AM) on August 1st, 2025.
2. Create a post scheduled for midnight (12:00AM) on August 2nd, 2025.
3. Go to create a new post and navigate to scheduling date/time selection menu.

Expected Results

Blue dot shows under dates August 1st and August 2nd.

Actual Results

❌ No blue dot shown under date August 1st in the scheduling date/time selection menu.

Additional Notes

By default, WordPress is set to UTC+0 for a time zone value, which is the value I used for my testing to get the failure condition. I'm able to get it to work if the site time zone is set to a UTC- value, but if its set to UTC+0 or above (like UTC+5), then it doesn't work properly. My expectation is that it should work regardless of the time zone set on the site, as long as the scheduled post is set for midnight on the 1st or later. Seems to be some issue with the way the code for this module is handling the time zone differential.

[butesa]

I did some research on why this bug depends on the time zone setting.

The REST request that is sent by the browser uses the timezone setting of the browser (aka system time zone of the user) to calculate the UTC representation of 'midnight'. On the server side, this UTC value gets converted to the time zone that is selected in the wordpress settings.

So for example, my browsers time zone ist UTC+2 (Central European Summer Time), so the REST request for August 2025 always contains this data, regardless of the wordpress time zone setting:

after=2025-07-31T22:00:00.000Z&before=2025-08-31T21:59:59.999Z

If I select UTC+1 as wordpress time zone (or any other time zone that is lower than my browsers time zone), this results in the following SQL query, which makes the blue dot for August 1st visible. But if you created a post with publishing date 2025-08-31 23:30:00, the blue dot would not be visible.

wp_posts.post_date < '2025-08-31 22:59:59' AND wp_posts.post_date > '2025-07-31 23:00:00'

If I select UTC+2 as wordpress time zone (my browsers time zone), this results in the following SQL query, which makes the blue dot for August 1st not visible. This problem is solved by the suggested pull request, which simply replaces < and > by <= and >=.

wp_posts.post_date < '2025-08-31 23:59:59' AND wp_posts.post_date > '2025-08-01 00:00:00'

If I select UTC+3 as wordpress time zone (or any other time zone that is higher than my browsers time zone), this results in the following SQL query, which makes the blue dot for August 1st not visible. This problem is not solved by the suggested pull request.

wp_posts.post_date < '2025-09-01 00:59:59' AND wp_posts.post_date > '2025-08-01 01:00:00'

So in fact, there are two bugs:

• The SQL query uses the wrong operators (< and > instead of <= and >=), which affects midnight-planned posts only if the time zone of the browser is the same as the wordpress time zone. This bug is in the server side PHP code and is fixed by the proposed pull request.
• The date limits in the REST request are calculated wrong (wordpress time zone should be used) if the time zone of the browser is not the same as the wordpress time zone. This bug seems to be in the client side Javascript code.