WordPress.org

Make WordPress Core

Opened 2 years ago

Last modified 2 months ago

#44597 new defect (bug)

Scheduling posts adds wrong seconds as post_date

Reported by: katsar0v Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 4.9.7
Component: Date/Time Keywords:
Focuses: Cc:

Description

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:
https://i.imgur.com/0KM1Jpw.png

Change History (3)

#1 @markparnell
5 months ago

  • Component changed from General to Date/Time

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

#2 follow-up: @lukasbesch
2 months ago

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
  1. 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.

#3 in reply to: ↑ 2 @markparnell
2 months ago

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.

Note: See TracTickets for help on using tickets.