Opened 8 years ago
Closed 8 years ago
#37554 closed defect (bug) (fixed)
update last checked time does not match the system time
Reported by: | ctienshi | Owned by: | swissspidy |
---|---|---|---|
Milestone: | 4.7 | Priority: | normal |
Severity: | normal | Version: | 3.1 |
Component: | Upgrade/Install | Keywords: | has-screenshots has-patch commit |
Focuses: | ui | Cc: |
Description
when checking for a new update it doesn't modify the last checked time correctly. I think it is a bug.
Attachments (4)
Change History (16)
#1
in reply to:
↑ description
@
8 years ago
- Focuses ui added
- Keywords needs-patch dev-feedback has-screenshots added
Replying to ctienshi:
when checking for a new update it doesn't modify the last checked time correctly. I think it is a bug.
#2
follow-up:
↓ 4
@
8 years ago
Hey ctienshi welcome to Trac! Thank you for submitting this report.
It is indeed correct that the 'last checked' time is not shown here. The version check result is stored for 60 seconds in the cache of WordPress before it could be checked again, so in theory the timer could be 60 seconds off. This however does not explain the offset shown in your screenshot.
Could you please check wether the same issue rises when you are creating a new post? And can you maybe check your timezone settings in the general settings under the 'Settings' menu item.
Eager to hear from you.
#4
in reply to:
↑ 2
@
8 years ago
@PieWP The timezone was not set properly. It was the issue. Thanks for the information. I think it would be better if WordPress automatically get the system time and accordingly update the timezone properly.
#6
@
8 years ago
- Keywords has-patch added; needs-patch removed
- Version changed from 4.5.3 to 3.1
The line in question on update-core.php
simply prints the current time and is actually quite useless:
printf( __( 'Last checked on %1$s at %2$s.' ), date_i18n( __( 'F j, Y' ) ), date_i18n( __( 'g:i a' ) ) );
I would rather remove that information instead of fixing it.
37554.patch doesn't work as it doesn't respect the current timezone / GMT offset and passes true
to date_i18n
instead of false
. 37554.diff fixes that. However, it's only a minor improvement as it's basically still the current date, but now can be 60 seconds off. That's probably why simply the current date was displayed (or perhaps the right data hasn't been available, idk).
Introduced in [15996].
#7
follow-up:
↓ 9
@
8 years ago
Oh, and regarding:
I think it would be better if WordPress automatically got the system time and accordingly updated the timezone properly.
You won't believe on how many systems the server time is horribly wrong or simply UTC. It's not reliable. I would rather use JavaScript to suggest a timezone during install or when changing settings. But that's for another ticket.
#9
in reply to:
↑ 7
@
8 years ago
Replying to swissspidy:
You won't believe on how many systems the server time is horribly wrong or simply UTC. It's not reliable. I would rather use JavaScript to suggest a timezone during install or when changing settings. But that's for another ticket.
True, I had a simular solution in mind. Set the timezone with PHP best effort in the installation process and auto correct it using javascript if enabled. Additionally automatically inheritance of the timezone once creating a new blog (MS installation) would be a nice to have as-well. If acceptable for a future release I'd gladly work out a patch for this.
#10
@
8 years ago
- Keywords dev-feedback removed
- Milestone changed from Future Release to 4.7
37554.diff looks good for now. Just need to remove the var_dump()
.
i checked for updates at 10.42pm last. But it shows as 5.09pm.