WordPress event date shows 1970? Trace the saved date before republishing

Capture the exact bad date and protect the visitor route

Download the event-date source and repair worksheet (Markdown, English)

Write down the affected event’s title, WordPress edit URL, public URL, displayed date, time zone and last known correct view. Check whether the editor also shows 1970 or only the signed-out public page does. Compare one unaffected event on the same site. If the bad date is live, ask the event owner to provide the approved schedule and a clear visitor-facing correction or contact route while the page is investigated.

Use the English worksheet to keep the approved date, source row, saved fields and public result separate. Avoid guessing a replacement date from a poster, old event edition or local device clock. Record when the problem first appeared and who owns the event record.

Compare the approved date with the saved record

Inspect both start and end fields in the event editor without immediately saving. Was this event created manually, duplicated, or imported? For a CSV import, compare the original row and the field mapping used for start date, end date and time. The provider recommends `YYYY-MM-DD` for its CSV date fields; a different source format or unmapped column needs review against the importer’s current instructions.[1][2]

Check whether the stored editor fields match the approved schedule after a reload. If an imported batch is affected, sample a few records before changing any of them. The provider documents that its importer may update matching existing events, so a bulk re-import is not a harmless diagnostic step. Keep the original file and a record of event IDs for the maintainer.[2]

Isolate import or editor causes in staging

On a staging copy with a recovery point, test one representative event. If the source row is wrong, correct the row or mapping and test a single import path there. If a duplicated event lost its dates, compare it with a fresh manually entered draft. If editor values are valid but the public view is wrong, ask the maintainer to inspect the rendering path rather than repeatedly overwriting the event.

Only after the record and source are checked should a maintainer test a possible theme or plugin conflict in staging. Isolate one change and compare the same event before and after. The provider recommends staging for this kind of test; switching live themes or disabling live plugins can disrupt registration and navigation.[3]

Release one correction and prepare a support handoff

Have the event owner approve the correct date and the smallest tested fix. After release, open the direct event page and calendar view signed out on desktop and phone. Confirm the approved start, end and time zone, and follow the current ticket or registration link if present. Recheck one unaffected event so the change did not alter another listing.

If 1970 returns, restore the tested baseline and send the maintainer a concise evidence packet: event ID and URLs, creation method, before/after editor fields, a sample date row without unrelated data, plugin versions and the staged result. Keep the approved schedule visible through the organizer’s chosen route until the public page is accurate.[1]