AEO for When Queries: Date, Schedule, and Timing Citation Strategies

AEO for when queries is the practice of formatting dates, times, schedules, and recurrence so answer engines extract and cite them accurately. The reliable levers are ISO-8601 datetime strings with explicit timezone, OpeningHoursSpecification or Event schema, and a dateModified that mirrors the most recent schedule edit.

TL;DR

When a user asks "when does X open", "when is the next Y", or "when did Z launch", AI engines extract a single datetime answer from the most authoritative source they can find. Win these queries by writing the answer as a complete ISO-8601 string with timezone, marking the page up with Event or OpeningHoursSpecification schema, and keeping dateModified fresh so the engine trusts your timing data over older mirrors.

Why when queries are different

Unlike how-to or definition queries, when queries have a single correct answer at a single point in time. That changes the optimization target in three ways:

Engines prefer the page that states the datetime most explicitly, not the page that ranks highest.
Freshness is decisive: a competitor with the same answer but a more recent dateModified usually wins.
Schema accuracy is non-negotiable; an OpeningHoursSpecification that contradicts the visible text is treated as untrustworthy.

ISO-8601 as the default format

Write every machine-readable datetime in full ISO-8601 with timezone offset:

2026-05-03T09:00:00-07:00 (preferred for events and meetings)
2026-05-03 (preferred for date-only fields like published_at)
PT2H30M (ISO 8601 duration for runtimes and recurring intervals)

Reader-facing copy can be friendlier ("May 3, 2026, 9:00 AM PDT"), but every machine-readable surface (frontmatter, JSON-LD, microdata) should use ISO-8601. Inconsistency between visible and structured data is one of the most common reasons engines reject a citation candidate.

Timezone disclosure

Never publish a time without a timezone, and never assume the reader's timezone matches yours. Best practice:

Always include the timezone abbreviation in visible copy ("9:00 AM PDT").
Always include the offset in JSON-LD (-07:00).
For events that span timezones, list the canonical timezone first and add a note for the secondary one.
For recurring events that respect daylight saving, encode the IANA zone ("America/Los_Angeles") rather than a fixed offset.

OpeningHoursSpecification for businesses

LocalBusiness pages benefit hugely from OpeningHoursSpecification, which Google AI Mode and Bing/Copilot use directly to answer "when is X open" prompts.

Minimum viable structure:

One OpeningHoursSpecification per recurring schedule.
dayOfWeek as an array of weekday URLs (https://schema.org/Monday, etc.).
opens and closes as 24-hour ISO-8601 time strings.
validFrom and validThrough on holiday-exception specifications.

For 24-hour businesses, set opens to 00:00 and closes to 23:59 rather than omitting the field; many extractors fail on missing values.

Event schema for one-off and recurring events

Use Event for single instances and EventSeries (with hasPart linking individual Event nodes) for recurring runs. Required fields for citation eligibility:

name, startDate (ISO-8601 datetime with timezone), endDate.
location (Place or VirtualLocation).
eventStatus and eventAttendanceMode (especially since 2020, when hybrid status became important).
offers when registration is required, even if free.

For cancellations or rescheduling, update eventStatus to EventCancelled or EventRescheduled and set previousStartDate. AI engines pick up these signals quickly and often surface them in answers as cautionary notes.

Date-range coverage

Some when queries have a range answer ("when is hurricane season", "when does enrollment open"). Encode ranges as a startDate and endDate pair in the body and the structured data. Avoid prose like "around late spring" without a numeric range alongside; engines cannot extract a citable answer from vague phrasing.

Holiday and exception handling

Most mistakes in when-query AEO are exception bugs: a business that ships standard OpeningHoursSpecification but forgets to publish holiday hours, or an event series whose individual instances skip a week without updating EventSeries.

Maintenance pattern:

Maintain a separate OpeningHoursSpecification per holiday or exception, with validFrom and validThrough scoped to that day.
Surface upcoming exceptions in visible copy ("closed July 4, 2026"), not only in JSON-LD.
Re-publish the page (update dateModified) whenever exceptions change. Engines weight freshness heavily on when queries.

Schedule-update cadence

For pages whose primary content is a schedule, treat dateModified the way an editor treats a publication date: refresh it any time a substantive schedule edit ships. AI engines compare dateModified across competing sources and prefer the most recently updated source, even when content is otherwise equivalent. A monthly review cadence is the minimum baseline; weekly review is appropriate for active event series and venue calendars.

Five examples that work

These patterns are routinely cited by Google AI Overviews, Perplexity, and ChatGPT search on when queries:

Apple's Worldwide Developers Conference event page — explicit ISO-8601 datetimes, timezone, eventAttendanceMode, recurring EventSeries.
NASA launch schedule pages — startDate and endDate per launch, eventStatus updated on scrubs, freshness via dateModified.
Major-league sports team schedule pages — EventSeries + per-game Event nodes, broadcast times in multiple zones.
Local-government city-hall hours pages — OpeningHoursSpecification with explicit holiday exceptions.
University academic calendar pages — long-form date ranges with both visible and structured data.

What all five share: ISO-8601 timestamps, explicit timezones, schema that mirrors the visible text, and a fresh dateModified.

Common mistakes

Mismatched visible time and JSON-LD time (e.g., visible "9 AM PT" but startDate "09:00:00Z"). Engines penalize the inconsistency by skipping the citation.
Omitting timezone in JSON-LD. Many extractors discard datetime fields without an offset.
Holiday hours communicated only on social media, never on the page itself.
Using prose like "this Tuesday" or "next week" without an absolute date. The page ages out within hours.
Forgetting to update eventStatus on cancellations. Old EventScheduled markup keeps surfacing in answers long after the event was cancelled.
One global "updated" footer that doesn't reflect the actual schedule edit. dateModified must be on the schema, not just in human-readable copy.

How to apply: when-query checklist

[ ] Every visible datetime has a corresponding ISO-8601 string with timezone in JSON-LD.
[ ] OpeningHoursSpecification published for any LocalBusiness page.
[ ] Event or EventSeries schema published for one-off and recurring events.
[ ] Holiday and exception specifications scoped with validFrom and validThrough.
[ ] eventStatus and eventAttendanceMode set explicitly.
[ ] dateModified updated on every substantive schedule edit.
[ ] Visible copy and JSON-LD agree on every timestamp.
[ ] Recurring schedules use IANA timezone strings, not fixed offsets.
[ ] No prose-only relative dates ("next Tuesday") without an absolute date alongside.
[ ] Page reviewed at least monthly during active scheduling periods.

FAQ

Q: Do I need both visible date copy and JSON-LD?

Yes. Visible copy is what readers and many AI extractors use for the citable quote; JSON-LD is what Google, Bing, and most schema-aware retrievers use for the canonical datetime. Skipping either reduces citation eligibility on at least one major engine.

Q: Should I publish times in the user's timezone or my own?

Publish in your event's canonical timezone first (where the venue is, or where the meeting nominally happens), with an offset note for the most likely secondary timezone. Engines prefer one canonical answer; multiple timezones in the structured data confuse extractors.

Q: How fresh does dateModified need to be?

Fresh enough to reflect your most recent schedule edit. For active venues and event series, that often means same-day updates. For static pages with no recent change, last-modified-now-thanks-to-CMS-redeploy timestamps actually hurt: engines penalize "updated" pages whose content has not actually changed.

Q: Does Event schema work for webinars and virtual events?

Yes. Use Event with eventAttendanceMode set to OnlineEventAttendanceMode and location as a VirtualLocation pointing to the join URL. The same fields apply to hybrid events with both physical and virtual locations.

Q: How do I handle DST transitions in recurring events?

Use IANA timezone strings ("America/Los_Angeles") rather than fixed offsets. Schedulers and structured-data parsers handle DST correctly when the IANA string is present; fixed offsets quietly drift twice a year.

Sources

Schema.org — Event. https://schema.org/Event
Schema.org — OpeningHoursSpecification. https://schema.org/OpeningHoursSpecification
Google — Event structured data. https://developers.google.com/search/docs/appearance/structured-data/event
Google — Local business structured data. https://developers.google.com/search/docs/appearance/structured-data/local-business
IANA — Time Zone Database. https://www.iana.org/time-zones