Fixing Date Format Errors in JSON-LD

What a valid date looks like

schema.org has two kinds of date value. A Date is a calendar day. A DateTime is a moment in time. Both are written in ISO 8601, and properties such as datePublished and startDate accept either.

The right formatter in each language

Nearly every bad date comes from a template that reuses the display format. The fix is to call a separate formatter for the markup, leaving the visible date as it is.

Two points are easy to miss. First, the offset must match when the date falls, not when the page is built: a post published in January in the UK is +00:00, one published in July is +01:00. Formatters that work from a named time zone such as Europe/London get this right automatically; a hard-coded +01:00 string does not. Second, storing everything in UTC and outputting Z is equally valid and avoids the question entirely, as long as the stored value really is UTC.

Empty, zero and placeholder dates

A date that was never set can surface in markup in several disguises. Each one tells you something about the code behind it.

• "": the template printed an empty field. The value is not a date, and a checker flags it as invalid.
• 1970-01-01T00:00:00+00:00 or 1970-01-01T01:00:00+01:00: an empty or null timestamp was treated as zero seconds, which is the start of 1970 in Unix time. Seeing 1970 anywhere in structured data means a missing value was formatted as if it existed.
• 0000-00-00 or 0000-00-00 00:00:00: an empty MySQL date column printed raw. There is no month zero or day zero, so this is invalid.
• Invalid Date or NaN-NaN-NaN: JavaScript tried to format something it could not parse.
• Today's date on every page: the template calls "now" when the real value is missing, so every post appears freshly published each time the cache is rebuilt.

The fix is the same in each case: test whether the source value exists before formatting it, and leave the property out when it does not. A missing optional date is better than a false one. If the property is required for a rich result, such as startDate on an Event, the event is not ready to be marked up until a real date exists.

Dates that are valid but wrong

A value can be perfectly formatted and still make no sense. The JSON Checker and Google's tools look at date pairs and at dates that have run out.

A related trap is a dateModified that changes on every page build even when nothing was edited. Some templates use the file's build time or the cache time. That does not break the markup, but it misstates freshness, and Google's guidance is that the modified date should reflect meaningful changes to the content.

A corrected block

This BlogPosting was previously printing "datePublished": "28 September 2026" from the theme's display format and an empty dateModified. After switching both to an ISO formatter and adding a check for the empty value, the output is:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Choosing Bulbs for a Shady Border",
  "datePublished": "2026-09-28T08:15:00+01:00",
  "dateModified": "2026-09-28T11:40:00+01:00",
  "author": {
    "@type": "Person",
    "name": "Robin Ashdown",
    "url": "https://www.example.co.uk/authors/robin-ashdown/"
  },
  "image": "https://www.example.co.uk/images/shady-border-bulbs-1200.jpg"
}
</script>

For a post that has never been edited, the template now either prints dateModified equal to datePublished or leaves it out; both are acceptable. It no longer prints an empty string.

A quick pattern check

If you want to scan exported markup yourself, this regular expression matches a date or a full date-time with an optional offset. Anything in a date property that does not match deserves a look:

^\d{4}-\d{2}-\d{2}(T\d{2}:\d{2}(:\d{2}(\.\d+)?)?(Z|[+-]\d{2}:\d{2})?)?$

It checks shape only. It will accept 2026-02-30, so for anything automated, parse the value with a real date library as well.

The fix, step by step

Keeping dates right

• Keep display and markup formats separate. Changing how dates look on the page should never change what goes into the structured data. Use two calls, not one shared variable.
• Store in UTC, format at the edge. Storing timestamps in UTC and converting only when printing avoids most offset mistakes and makes Z output trivially correct.
• Test across the clock change. Keep one page dated in winter and one in summer in your template test list.
• Automate expiry. Build priceValidUntil and validThrough from the same data that ends the sale or closes the job, so they cannot drift.
• Check after migrations. Imports between platforms often reset published dates or carry them over as text. Re-run the date checks after any move.

For AI-generated markup, where the model itself chooses the date, the AI schema date guide covers the different set of mistakes that appear there.