Yoast structurated data and the_date and the_modified_date timestamps doesn't sync

[wpsumo]

• I've read and understood the contribution guidelines.
• I've searched for any related issues and avoided creating a duplicate issue.

Please give us a description of what happened.

Yoast structured data datePublished and dateModified is not syncronized and displying the same as echo

datePublished | 2020-10-02T12:04:23+00:00
dateModified | 2021-03-08T15:56:52+00:00

<?php the_time( 'c' ); ?>
<?php the_modified_date( 'c' ); ?>

Posted on 2020-10-02T14:04:23+02:00.
Modified 2021-03-08T17:56:52+02:00.

It's a diff of 2hours. Any idea why?

Please describe what you expected to happen and why.

The timestamps to be identical.

How can we reproduce this behavior?

1. Just steup a sandbox site
2. Install yoast
3. Echo the_date and the_modified_date

Technical info

• If relevant, which editor is affected (or editors):

• Classic Editor
• Gutenberg
• Classic Editor plugin

• Which browser is affected (or browsers):

• Chrome
• [x ] Firefox
• Safari

Used versions

• WordPress version: 5.6.2
• Yoast SEO version: 16.0

[Djennez]

They look the same, with the difference being that one is output in a different timezone.

datePublished | 2020-10-02T12:04:23+00:00
dateModified | 2021-03-08T15:56:52+00:00

These are UTC/GMT dates.

Posted on 2020-10-02T14:04:23+02:00.
Modified 2021-03-08T17:56:52+02:00.

These are the same, but from UTC+2.

[wpsumo]

@Djennez Oh that's right but why does Yoast fetch UTC/GMT dates and not what the end user specified into wordpress settings as timezone under /wp-admin/options-general.php?

To me that seems like the issue and would make sense for Yoast to listen to this value in the CMS and define the same in structurated data JSON-LD as the user will do on the frontend?

Do you always use UTC/GMT or look at server timezone? Why not switch to CMS timezone specified by the user? As it's more relevant for everyone. Plus the benefit of correct and syncornized ouput.

[Djennez]

I believe we generally use +00, at least in the code internally and in output for machines, because it's the easier implementation and is less prone to errors. We have seen several instances where +01:00 or another positive or negative integer was misinterpreted by humans and/or systems.

2021-03-08T15:56:52+00:00 and 2021-03-08T17:56:52+02:00 are factually still the same date, just a different notation. Can you provide an example on how this different output is breaking your instances, or is making things unclear?

[wpsumo]

Okay I may not see some complexity here but I do see the issues not stating the same for the user as in structurated data. It is technically violation of the guidelines. It's like showing a review markup and state rating 4 in json-ld and 1 in the frontend. It always have to display the same. Even if things as publish and modified date might be more acceptable I do not agree that they shouldn't syncronize.

Yes you can agrue that ok solve it by setting your timezone to +00. But that defines the point of displaying the real dates. +2 in oen case but it can diff in dates and more hours if it's in other timezones. And that would be more wrong to display different dates.

This becomes even more of a problem once the site is international and multilingual. So my stand is still that this is wrong to not look at the timezone specified by the user. I still beleive this is something you can solve and the problems you faced before could be solved. Just because we faced a blocker or higher mountain we can not stop leave it.

If you are +8? do you still belive using +00 is correct? Meaning it can diff close to a half day in the dates and it will be different dates if it's actually published or modified after 17:00?

The way it's breaking is that it is not saying the same information and that is wrong. At least give us a hook to change the UTC via code so we can set it to UTC+2 or different depending on what the user want.

[Djennez]

2021-03-08T15:56:52+00:00 and 2021-03-08T05:56:52-10:00 and 2021-03-08T21:56:52+06:00 are still the same date and time... This goes for every timezone that exists. So I'm really not sure what the issue is here.

[wpsumo]

The time is not the same meaning it is not the same data displayed frontend (what the user sees) and what you tell the bots/crawlers that is facts.

2021-03-08T15:56:52+00:00 and 2021-03-09T03:56:52+12:00 is not the same date.

[Djennez]

Please see https://en.wikipedia.org/wiki/ISO_8601#Time_offsets_from_UTC for an explanation of why both of those are exactly the same date and time. And a specific quote example from that page:

The following times all refer to the same moment: "18:30Z", "22:30+04", "1130−0700", and "15:00−03:30".

Going with the fact that they are both the same: which exact issue do you experience?

[wpsumo]

There is no way to say timezone. Neither Yoast nor me specify the timezone as it's not ecstatically nice frontend.

In my example I use "published x hours or x days ago." and with published x hours ago it especially become wrong. And as the rest is based on WordPress specified timezone while Yoast stick to UTC 00.

They in most cases are the same date, but I still disagree with them being the same point in time. As the hours can diff up to changing the date. How do you specify to the user or even via JSON-LD that 2021-03-09 and 2021-03-08 is the same date? As you have not specified either of their UTC.

I might be stubborn, but I need to be convinced in the way I understand here as I'm still not inline with this being the same. In your explanation you bring up UTC without using UTC how would we know this is the same date as there is no reference in this case to use. The fore I disagree with the format of not using what the install is saying.

As you have a strong argument they are the same with the offsets from UTC explain to me in an easy way why they are the same and what I'm missing here. To me even if this is the case I see a much less confusion and correct data to display same timezone and same informaiton in frontend fetched via WP and JSON-LD fetched by yoast from UTC 00.

There is no reason to sue different UTC here. I hope I've made my reason to it clear if not let me know.

[Djennez]

Since you are referring to our schema, we do output the timezone in there:
"datePublished":"2021-03-17T13:57:20+00:00","dateModified":"2021-03-17T13:57:22+00:00"

But also in our metadata, we output the timezone:

<meta property="article:published_time" content="2021-03-17T13:57:20+00:00" />
<meta property="article:modified_time" content="2021-03-17T13:57:22+00:00" />

+00:00 is the timezone designator (TZD).

Since I believe these are the only instances of datetime we output on the frontend, it looks to me that we always include the TZD.

If you write code that uses these values to show a user "published xx days ago" (that is what I get from your message), it's up to you how you implement this, and how you want to take care of the TZD. And yes, 2021-01-01T23:00+00:00 is the same point in time as 2021-01-02T01:00+02:00. So the date changes. But if you calculate the UTC from the latter correctly, you will end up with the first date. That's just how that works.

[wpsumo]

That is right my bad and so does the 'c'. 

Well the issue is I do not display the UTC and using UTC as  displayable frontend. As it's not the most esthetical way of displaying  time frontend.

But I might anyhow consider changing it to 00:00UTC in wp admin as I figure out that this anyhow is not controlled by WPML as different time zones per country anyhow at the moment. Therefore, I could just revert to 0 as well. As xxx days ago will be referenced to 0 for a robot. And for user it doesn't matter right now as it's not multilingual adjusted by WPML.

But if WPML would support different time zones in the future I would like to display it in the meta and schema output as in frontend.

Think about it in the future at least, thanks Djennez for the discussion! :)