WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#17278 closed defect (bug) (fixed)

Updater shows last check in 1970

Reported by: hebbet Owned by: westi
Milestone: 3.2 Priority: normal
Severity: major Version: 3.2
Component: Upgrade/Install Keywords: needs-patch
Focuses: Cc:

Description

i justed updated my local install of wordpress trunk and noticed Wordpress Updates shows "Last checked on January 1, 1970 at 12:00 am."

I also tested this on a sever and got the same issue.

It was correct a few days ago.

Attachments (1)

17278.diff (534 bytes) - added by greuben 3 years ago.

Download all attachments as: .zip

Change History (17)

comment:1 nacin3 years ago

  • Milestone changed from Awaiting Review to 3.2

Looks like the transient may have expired and we're doing a time conversion on false/0.

comment:2 ocean903 years ago

printf( __('Last checked on %1$s at %2$s.'), date_i18n( get_option( 'date_format' ) ), date_i18n( get_option( 'time_format' ) ) );

Their is no transient or I'm missing something?

comment:3 ocean903 years ago

Reverting [17747] solves the issue.

comment:4 nacin3 years ago

  • Owner set to nacin
  • Status changed from new to reviewing

Hmm.

comment:5 ocean903 years ago

  • Severity changed from normal to major

The current time is now missing, the same behaviour is on options-general.php.

greuben3 years ago

comment:6 greuben3 years ago

  • Keywords has-patch added

Timestamp is missing.

comment:7 DH-Shredder3 years ago

  • Cc mike.schroder@… added

Seems to me that the question is whether date_i18n() should be returning a result based on the current datetime/timestamp if no $unixtimestamp is provided.

If the answer is yes, then the attached patch seems to be the proper route.

If the answer is "that's not what this function is for", then that's another story altogether, and the originating code should likely be grabbing a timestamp elsewhere first.

comment:8 greuben3 years ago

  • Keywords needs-patch added; has-patch removed

My bad, the problem is not timestamp. gmdate and date take local time if timestamp is not provided.

The second parameter in date and gmdate is type casted internally to long integer. Hence false becomes zero and the wrong time is generated

Try this:

echo gmdate( $dateformat );
echo gmdate( $dateformat, false );

comment:9 greuben3 years ago

I still think passing current timestamp seems proper rather than

if ( $i ) {
   $datemonth = $wp_locale->get_month( $datefunc( 'm', $i ) );
} else {
   $datemonth = $wp_locale->get_month( $datefunc( 'm' ) );
}

comment:10 cklosows3 years ago

The diff in attachment:17278.diff fixed the issue on my local install of the latest trunk.

On a ticket related note, should the Summery be updated to reflect usage of the date_i18n() function returns 1970-01-01 instead of 'Updater.....' since this is an issue in the root function, not just the updater? Might help avoid duplicates.

Last edited 3 years ago by cklosows (previous) (diff)

comment:11 knutsp3 years ago

  • Cc knut@… added

comment:12 cklosows3 years ago

  • Cc cklosows added

comment:13 westi3 years ago

  • Owner changed from nacin to westi

comment:14 westi3 years ago

[17747] - removed far too much code from what I can see.

This also affects options > general

comment:15 westi3 years ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

In [17841]:

Restore the functionality of date_i18n to pre [17747] so that is works without a provided timestamp again. Fixes #17278.

comment:16 westi3 years ago

For reference the commit that introduced the compat code - [8199]

Note: See TracTickets for help on using tickets.