Make WordPress Core

Opened 13 years ago

Closed 13 years ago

Last modified 13 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 13 years ago.

Download all attachments as: .zip

Change History (17)

#1 @nacin
13 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
13 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
13 years ago

Reverting [17747] solves the issue.

#4 @nacin
13 years ago

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

Hmm.

#5 @ocean90
13 years ago

  • Severity changed from normal to major

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

@greuben
13 years ago

#6 @greuben
13 years ago

  • Keywords has-patch added

Timestamp is missing.

#7 @kirasong
13 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
13 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
13 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
13 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 13 years ago by cklosows (previous) (diff)

#11 @knutsp
13 years ago

  • Cc knut@… added

#12 @cklosows
13 years ago

  • Cc cklosows added

#13 @westi
13 years ago

  • Owner changed from nacin to westi

#14 @westi
13 years ago

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

This also affects options > general

#15 @westi
13 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
13 years ago

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

Note: See TracTickets for help on using tickets.