Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Saying local post / modified dates are UTC when they are local #1450

Closed
webaware opened this issue Jan 3, 2018 · 5 comments

Comments

Projects
None yet
4 participants
@webaware
Copy link
Contributor

commented Jan 3, 2018

The post_date / post_modified fields of a post are in local time, not UTC. The plugin is reporting these as UTC (by appending Z to the timestamps) when they can be any timezone. Either the timezone needs to be reported accurately, or the UTC versions of those fields should be used. They are post_date_gmt and post_modified_gmt respectively.

PR coming.

@githubeing

This comment has been minimized.

Copy link

commented Jan 18, 2018

i've tested and that's true, i confirm the bug
e. g., post has the following sql database fields:

post_modified | post_modified_gmt
2018-01-18 01:10:43 | 2018-01-17 22:10:43

and sitemap has the following:

<lastmod>2018-01-18T01:10:43Z</lastmod>

but when i change site's timezone to UTC, the old articles continue displaying with wrong dates, but new posts, that were modified after I changed timezone, are displayed with correct utc dates in sitemap.

that is because the plugin's php code only accesses the post_modified field and never reads post_modified_gmt:

/wp-content/plugins/all-in-one-seo-pack/modules/aioseop_sitemap.php
2482:	if ( $p->post_modified > $archives[ $date ]->post_modified ) {
2483:		$archives[ $date ] = $p;
2484:	}
...
2531:	if ( $p->post_modified > $authors[ $p->post_author ]->post_modified ) {
2532:		$authors[ $p->post_author ] = $p;
...
2626:	$date = $post->post_modified;

but when writing the sitemap, the dates are written in utc.

one must not use post_modified local date, because it depends on what timezone was active when the post was saved to db. if current timezone differs, then you cannot even calculate what was that time, because you no longer know, which timezone was active at that moment.

one must use only post_modified_gmt utc date, because it never changes.

@githubeing

This comment has been minimized.

Copy link

commented Jan 18, 2018

@michaeltorbert , i'm mentioning you explicitly, in order to make github send you a notification about my previous comment

@michaeltorbert

This comment has been minimized.

Copy link
Member

commented Jan 18, 2018

@githubeing Is there something you specifically need me for?

@githubeing

This comment has been minimized.

Copy link

commented Jan 18, 2018

@michaeltorbert , you added a label needs testing -- i just wanted to let you know, that the bug does reproduces, i tested it. -- so that maybe it somehow changes the issue's status to bug, confirmed or something... -- that's all. excuse me, if i've bothered you

@michaeltorbert

This comment has been minimized.

Copy link
Member

commented Jan 18, 2018

  1. Just because I added a label, that doesn't mean you need to mention me specifically in a followup comment. I added the label because it needed it and I saw it first.
  2. While we certainly appreciate your contribution, that label is a signal that one of our testers should test the PR.
  3. When you mention people unnecessarily, that pulls us away from what we're working on, hindering productivity.

@semperfiwebdesign semperfiwebdesign locked and limited conversation to collaborators Jan 18, 2018

@michaeltorbert michaeltorbert added this to the 2.7 milestone Mar 22, 2018

@wpsmort wpsmort modified the milestones: 2.7, 2.8 May 15, 2018

@wpsmort wpsmort modified the milestones: 2.8, 2.6 May 21, 2018

@wpsmort wpsmort removed their assignment May 22, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.