Make WordPress Core

Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#17278 closed defect (bug) (fixed)

Updater shows last check in 1970

Reported by: hebbet's profile hebbet Owned by: westi's profile 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 12 years ago.

Download all attachments as: .zip

Change History (17)

#1 @nacin
12 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.

#2 @ocean90
12 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?

#3 @ocean90
12 years ago

Reverting [17747] solves the issue.

#4 @nacin
12 years ago

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

Hmm.

#5 @ocean90
12 years ago

  • Severity changed from normal to major

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

@greuben
12 years ago

#6 @greuben
12 years ago

  • Keywords has-patch added

Timestamp is missing.

#7 @mikeschroder
12 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.

#8 @greuben
12 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 );

#9 @greuben
12 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' ) );
}

#10 @cklosows
12 years ago

The attached patch in 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.

Version 0, edited 12 years ago by cklosows (next)

#11 @knutsp
12 years ago

  • Cc knut@… added

#12 @cklosows
12 years ago

  • Cc cklosows added

#13 @westi
12 years ago

  • Owner changed from nacin to westi

#14 @westi
12 years ago

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

This also affects options > general

#15 @westi
12 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.

#16 @westi
12 years ago

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

Note: See TracTickets for help on using tickets.