Scheduling posts adds wrong seconds as post_date

[katsar0v]

Whenever I schedule a random post on wordpress, for example I give the date 2 August 2018 18:00, wordpress inserts the wrong seconds into the database in post_date. post_date of the example given would be something like 2018-08-02 18:00:22. WordPress would add these 22 seconds, which is wrong, because I have defined only hours and minutes in the GUI, so seconds should not be just randomly defined.
Here is a database example:

[markparnell]

@katsar0v thanks for the report. I've noticed this too - I suspect the seconds are automatically added from the current time (rather than being truly random).

Are you able to provide details of a scenario where those seconds actually cause problems? I agree it's not entirely logical, but does it break anything?

[lukasbesch]

I've noticed this on a (high traffic) site running WooCommerce and disabled WP_CRON, running a real cronjob every minute. The new products were released a minute later than estimated.

I see these options to resolve the issue:

1. Provide an input field for seconds. This has to be implemented on several locations:
   • Meta box on post edit screen (Classic Editor)
   • Meta box on post edit screen (Gutenberg)
   • Quick edit on post list screen
   • Bulk edit on post list screen

2. Set the seconds to 00 when scheduling a post.

@markparnell You mentioned the value for the seconds should be random.
If I understand it correctly, the reason is that if you are using regular WP_CRON, the load impact of publishing a large number of scheduled posts would be distributed on multiple requests rather than only the first after second zero.
If this is the case, we could check if WP_CRON is enabled before setting it to the current time (or even a random value), else set it to zero.

From an editors perspective, I think the seconds input would make more sense as it allows finer control of time-critical content.

[markparnell]

Replying to lukasbesch:

@markparnell You mentioned the value for the seconds should be random.
If I understand it correctly, the reason is that if you are using regular WP_CRON, the load impact of publishing a large number of scheduled posts would be distributed on multiple requests rather than only the first after second zero.

I was just responding to the OP's comment regarding the seconds appearing to be random - clarifying that while I haven't specifically tested it, I suspect that the seconds are automatically picked up from the current time rather than actually being randomly generated. Your point about publishing a large number of posts effectively simultaneously is a fair one though. I'm not sure how much of an impact that would really have, but it's certainly something to keep in mind.

If this is the case, we could check if WP_CRON is enabled before setting it to the current time (or even a random value), else set it to zero.

My immediate concern with that approach is that it would be based on whether WP_CRON is enabled at the time of scheduling the posts, but that could change before they are actually published. Admittedly that's not likely to change often on a production site, so it's a fairly edge case.

From an editors perspective, I think the seconds input would make more sense as it allows finer control of time-critical content.

Agreed.

[pbearne]

It may be SQL that is adding the seconds

I don't think it is going to get changed.

Will close

[davidtheplumber]

This behavior occurs because WordPress automatically adds the current seconds from the server time when a post is scheduled, even if only hours and minutes are specified. To fix this, you can use the save_post hook to override the seconds value in post_date. Here's a solution:

<?php
add_action('save_post', function($post_id) {
    $post = get_post($post_id);
    if ($post->post_status === 'future') {
        global $wpdb;
        $corrected_date = date('Y-m-d H:i:00', strtotime($post->post_date));
        $wpdb->update(
            $wpdb->posts,
            ['post_date' => $corrected_date, 'post_date_gmt' => get_gmt_from_date($corrected_date)],
            ['ID' => $post_id]
        );
        clean_post_cache($post_id);
    }
});

This ensures that the post_date and post_date_gmt fields have seconds set to 00.

[pbearne]

@davidtheplumber
I can see how this will fix this
Looking at the core code, it seems to me that we don't set the seconds if a date/time is pass in
if not then we call current_time( 'mysql' ) which does

I can see the case for changing this to set to the seconds to 00
But we will need some more core dev to wade in before we do this.

[davidtheplumber]

Replying to pbearne:

@davidtheplumber
I can see how this will fix this
Looking at the core code, it seems to me that we don't set the seconds if a date/time is pass in
if not then we call current_time( 'mysql' ) which does

I can see the case for changing this to set to the seconds to 00
But we will need some more core dev to wade in before we do this.

Sure thing we can wait for them.