Fixing Date Format Errors in AI-Generated Schema

Why generated dates go wrong

Four habits of language models explain nearly every date problem in generated markup.

• No sense of today. A model does not know the current date unless it is told. When it has to infer a year, it leans towards the years it saw most during training, which are always in the past. A post published this spring can come back dated a year or two earlier.
• Reading dates as prose. "Updated last Tuesday", "Posted 3 weeks ago" and "Spring 2026" are meaningful to a reader but give the model nothing exact. It either guesses a day or copies the phrase into the markup as text.
• Mixed conventions. Training text is full of American dates. A page that says 04/05/2026 means 4 May to a UK reader, and 5 April to much of what the model has read.
• The generation day as a default. If the model or a script around it fills dateModified with "now", every page appears to have been updated on the day you generated its markup, whether or not the content changed.

Each of these produces a date that may be valid in format but wrong in fact, which is why the checks below compare values with your CMS rather than only running a validator.

The format schema.org and Google expect

Date properties such as datePublished, dateModified, uploadDate and startDate take an ISO 8601 value. There are two shapes you will use, and one variant of the second.

Google's Article documentation recommends including time zone information in datePublished and dateModified; without it, Google falls back to the time zone Googlebot uses, which may shift your date by a day around midnight. For events, a start time without an offset is ambiguous for anyone searching from another zone.

What generated markup produces instead

The UK offset trap

This one catches UK sites in particular. The UK uses Greenwich Mean Time, offset +00:00, in winter, and British Summer Time, offset +01:00, from the last Sunday in March to the last Sunday in October. The right offset depends on the date being described, not on the date you generate the markup.

A model told the site is in the UK, or copying an offset it saw elsewhere on the page, will often apply one offset to every date. That gives results like this:

"datePublished": "2026-01-12T09:00:00+01:00"   wrong: January is GMT
"datePublished": "2026-01-12T09:00:00+00:00"   right
"dateModified":  "2026-07-03T16:20:00+00:00"   wrong if the edit was at 16:20 local time
"dateModified":  "2026-07-03T16:20:00+01:00"   right

A wrong offset moves the moment by an hour. That rarely matters for an article, but it changes the start time of an event shown in search, and a post published just after midnight can appear to have been published the previous day.

Events that straddle a clock change need each date given its own offset. A course that starts on a Saturday in late October and ends the following weekend has a startDate in BST and an endDate in GMT.

Dates that are well formed but wrong

Once every value is in ISO 8601, check that the dates make sense together and against the page. These are the logic errors generated markup produces most often.

• The training-cutoff year. datePublished a year or more earlier than the date shown on the page. Always compare the year, not only the day and month.
• dateModified before datePublished. Usually the two were swapped, or the model read an "originally published" note as the update date.
• dateModified equal to the generation day. If every block you generated this week has this week's date, it is recording your tool run, not a content change.
• Visible date and markup disagree. Google advises showing a clear date on the page and keeping it consistent with the structured data. If the page says "Updated 2 June" and the markup says 9 June, fix whichever is wrong.
• A future datePublished. A scheduled post generated before it went live may carry its scheduled date, or a guessed date later than today. Publication dates should never be in the future.
• endDate before startDate on an Event or Course instance, often because the model read a date range in the day-first order and the end date in month-first order.
• Expired offers. A generated priceValidUntil in the past tells search engines the price has lapsed. Leave the property out unless the page states when the price ends.

When to change dateModified

Update dateModified when the main content changes in a way a reader would care about: new information, corrected facts, a rewritten section. Do not change it for a typo, a new sidebar widget or regenerated markup. Bumping the date without a real change does not make a page fresher in any useful sense, and a date that moves every time you touch the template becomes meaningless to readers and search engines alike.

The fix, step by step

Outputting dates from your platform

The most durable fix is to stop typing dates into markup at all. Keep the rest of the generated block, and fill the date properties from the same fields that drive the visible date.

WordPress

In a theme template, get_the_date( 'c' ) and get_the_modified_date( 'c' ) return ISO 8601 values with the site's offset applied for that date, so BST and GMT are handled for you, provided the time zone in Settings, General is set to a city such as London rather than a fixed UTC offset. Most SEO plugins already output these dates in their own Article markup, which is another reason not to duplicate Article in a generated block.

"datePublished": <?php echo wp_json_encode( get_the_date( 'c' ) ); ?>,
"dateModified": <?php echo wp_json_encode( get_the_modified_date( 'c' ) ); ?>

Shopify

Liquid's date filter accepts strftime codes. For a blog article, {{ article.published_at | date: '%Y-%m-%dT%H:%M:%S%:z' }} gives a value with an offset. Check the store's time zone in the admin settings first, because the output uses it.

Custom sites and frameworks

In JavaScript, new Date(value).toISOString() gives a UTC value ending in Z, which is valid and avoids offset arithmetic. In PHP, $date->format( DATE_ATOM ) on a DateTime with the Europe/London zone gives the correct seasonal offset. In a static site generator, most date helpers have an ISO format option; use the file's front matter dates, not the build time, or every page will show the day of the last deploy.

Type-specific date rules worth knowing

Durations deserve a note because generators often mix them up with dates. A duration begins with P, and anything under a day needs the T before hours and minutes: PT20M is twenty minutes, while P20M means twenty months.