[wp-trac] [WordPress Trac] #61652: Use `<input type="datetime-local">` for scheduling - performance and usability enhancement

[WordPress Trac]

#61652: Use `<input type="datetime-local">` for scheduling - performance and
usability enhancement
--------------------------------------------+-----------------------------
 Reporter:  edent                           |      Owner:  (none)
     Type:  enhancement                     |     Status:  new
 Priority:  normal                          |  Milestone:  Awaiting Review
Component:  Date/Time                       |    Version:  6.5.5
 Severity:  normal                          |   Keywords:
  Focuses:  ui, accessibility, performance  |
--------------------------------------------+-----------------------------
 When scheduling a blog post to be published later, user have to use this
 WordPress control:

 [[Image(https://shkspr.mobi/blog/wp-content/uploads/2023/09/WP-Date-
 Picker.png)]]

 I find it mildly annoying. I don't get why part of it is a dropdown. And
 the number fields don't pop up my phone's number keypad. And I have to
 look at a different calendar if I want to schedule something for a
 Saturday.

 The back end code for validating the POST'd timestamp is complex and
 inefficient - https://github.com/WordPress/wordpress-
 develop/blob/29c2f0154c180ecf92448e0f3f4e6430745c868b/src/wp-
 admin/includes/post.php#L178

 Replacing the various `<input>`s with `<input type="datetime-local">`
 makes the front end much simpler. It works on all browsers and is easier
 to use on mobile devices.

 When the element is submitted, it POSTs an ISO8601 / RFC 3339 string.
 Something like 2023-08-27T12:34

 This makes the back end much simpler as well. The validation is either:


 {{{
 $dateTime = DateTime::createFromFormat( "Y-m-d\TH:i",
 $post_data['dateTime'] );
 if ( $dateTime == false ) {
    return new WP_Error( 'invalid_date', __( 'Invalid date.' ) );
 }
 }}}

 or

 {{{
 $dateTime = $post_data['dateTime'];
 if ( strtotime($dateTime) == false ) {
    return new WP_Error( 'invalid_date', __( 'Invalid date.' ) );
 }
 }}}

 Based on my very rough profiling, I expect the new function to be about
 twice as fast, albeit using about twice the memory. But we're talking
 fractions of seconds and hundreds of bytes.

 There's a little more discussion on my blog post -
 https://shkspr.mobi/blog/2023/09/should-the-wordpress-publish-scheduler-
 use-datetime-local/

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/61652>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform