Support Forum » User Profile

Forum Replies Created

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • vubaivubai
    Participant

    Hi,

    so the issue here is that the value stored in the database is a WordPress "timestamp + offset" not a true Unix timestamp as reported in the Meta Box docs and the former are being phased out from WordPress core as they're causing issues as reported here:
    https://make.wordpress.org/core/2019/09/23/date-time-improvements-wp-5-3/

    Also note that date_i18n() is now deprecated in favor of wp_date() as also reported in the article above.

    The example code you pasted above works as long as you're not using standard PHP date functions that expect a true Unix timestamp otherwise the time zone will be messed up.
    Expanding on your example here you can see that the output of wp_date() is wrong if you have non-UTC time zone in your WordPress settings:

    
    $date_time = rwmb_meta( 'datetime' );
    echo date_i18n( 'F d, Y H:i', $date_time );
    echo wp_date( 'F d, Y H:i', $date_time );
    

    Hope this make my point more clear.

    vubaivubai
    Participant

    I'm also facing this issue.

    Currently there are no time zone conversion when the timestamp is displayed in the datetime widget so the displayed date is wrongly offsetted if your current time zone is not UTC.

    I think the correct way of handling this would be to format the timestamp with the time zone set in WordPress settings in order to get a localized date to work on.

    I also tried using a custom parse function (https://trentrichardson.com/examples/timepicker/) for the widget but this is a no-go as all parameters under js_options are treated as strings. There is currently no way of specifying a custom JavaScript function in the field settings.

    in reply to: Bug: MB Admin Columns alters custom queries #13887
    vubaivubai
    Participant

    Thank you for this quick release!

Viewing 3 posts - 1 through 3 (of 3 total)