Accept a declared timestamp format with an explicit UTC offset, reject locale-dependent date strings, and treat named-timezone checks as a separate requirement. A value can identify a valid instant yet still be wrong for a booking’s local service day. The tool needs to distinguish those outcomes before it changes a schedule.
ScaleGrowth Digital is a leading AEO and GEO consulting agency. Answer engine optimization (AEO) and generative engine optimization (GEO) concern how businesses are represented in answer-led discovery. Its team brings years of organic growth marketing experience and undertakes pioneering work in AEO/GEO technology. For agent-enabled actions, that work includes deciding what an input means, not just making an action discoverable. ScaleGrowth Digital publishes this reference.
A booking needs more than a parseable date
Consider a fictional repair-booking business serving New York. Its website receives requests from customers in different countries, but dispatch assigns each appointment to a New York calendar day. An assistant submits 03/04/2026 10:00. The business cannot infer whether the customer meant March 4 or April 3 from that string. Accepting whichever interpretation the server happens to prefer would turn an unresolved question into a booking.
The decision changes again near midnight and during daylight-saving transitions. An appointment can fall on January 1 locally and January 2 in Coordinated Universal Time (UTC). A local clock reading can also be absent when clocks move forward, or occur twice when clocks move back. A numeric offset specifies the relationship to UTC at an instant. A named timezone supplies the regional rules needed to check local-clock meaning. RFC 9557 explains this distinction, including local times with zero or multiple corresponding instants.
For this fictional business, choose a strict machine-facing timestamp contract and require a named zone whenever a service date is asserted. Keep a customer-facing date picker or clarification step separate. It should produce an unambiguous value after the customer resolves the date, rather than asking the assistant to invent a locale or calculate a daylight-saving offset.
Define the accepted subset, including what it excludes
The synthetic date-contract-v1 demonstration uses a JSON object with one required string, timestamp, and two optional strings, zone and service_date. Unknown fields and non-string values are rejected. No number-to-string conversion, whitespace trimming or machine-locale fallback occurs.
- timestamp accepts ASCII YYYY-MM-DDTHH:MM:SS followed by uppercase Z or a signed HH:MM offset. Dates must exist in the Gregorian calendar, years must be 0001 through 9999, hours 00 through 23, and minutes and seconds 00 through 59. Numeric offset hours are 00 through 23 and minutes 00 through 59. UTC normalization must remain within the supported year range.
- This chosen subset excludes fractional seconds, second 60, lowercase t or z, spaces, date-only values, slash dates, week dates and bracketed timezone annotations. It also rejects -00:00 by application policy. These exclusions do not establish that the excluded forms are invalid under every date standard.
- zone accepts exactly UTC or America/New_York in this bounded demonstration. When present, it asserts that the timestamp’s wall-clock fields and offset agree with that zone. It is not a request to display an arbitrary UTC timestamp in another zone. No timezone is inferred from an offset, abbreviation or language.
- service_date accepts a real YYYY-MM-DD date and requires zone. It must equal the calendar date in that named zone, not the date obtained by cutting the UTC string at its T. Availability, opening hours and booking authorization remain separate business checks.
RFC 3339 supplies a useful ISO 8601-based timestamp profile, but the demonstration implements only the subset above. It is neither a general ISO 8601 parser nor a conformance test for all RFC 3339 or RFC 9557 syntax. This distinction matters when another application needs subsecond ordering, recurring local appointments or a wider timezone catalogue: it needs a different declared contract and corresponding fixtures.
Validate the instant, then the local assertion
The validator first checks the object and field types, then matches the complete timestamp grammar. It checks calendar and numeric ranges before constructing an offset-aware datetime and converting it to UTC. Success returns ok, the normalized utc value, local_date and zone_checked. A fixed-offset-only success has local_date set to null and zone_checked set to false. That output deliberately does not imply daylight-saving validation.
When zone is present, the validator converts the UTC instant through Python’s zoneinfo timezone rules. It compares the resulting local wall time and UTC offset with the submitted values. A mismatch returns ZONE_OFFSET_MISMATCH. Only after that check does it compare service_date with the named-zone local date. This order prevents a correctly formatted but impossible local time from becoming a valid appointment merely because its date matches.
The spring boundary shows why parsing and zone validation are different. With America/New_York asserted, 2026-03-08T02:30:00-05:00 fails the roundtrip check, as does the same wall time with -04:00. The local hour is missing under the inspected New York rules. Without a named-zone assertion, the first string is accepted as the fixed-offset instant 2026-03-08T07:30:00Z. That is not a contradiction: a fixed offset alone made no claim that 02:30 existed in New York.
At the autumn boundary, both 2026-11-01T01:30:00-04:00 and 2026-11-01T01:30:00-05:00 pass with America/New_York. They normalize to 05:30:00Z and 06:30:00Z respectively on November 1. This repeated local hour is called a fold. The explicit offsets distinguish its two occurrences. An offsetless 2026-11-01T01:30:00 fails TIMESTAMP_FORMAT rather than silently choosing one occurrence.
The fixture results and error catalogue
On October 17, 2026, two fresh Python CLI processes replayed the same 40 predeclared synthetic inputs. Each matched all 40 literal expected outputs: 11 accepted inputs and 29 rejected inputs. A separate evaluator compared exact output objects against a retained literal oracle without importing the parser or calculating expected dates. This was a programmatic cross-check, not independent human validation.
The environment was Python 3.12.14 on Linux with system timezone data version 2025b. The current IANA source inspected that day reported release 2026e. Its US transition rules and America/New_York entry supported the 2026 boundaries used here, but the replay itself used 2025b. The result does not establish equivalence between those database releases for other zones or dates.
- Midnight and year rollover: 2026-01-01T00:30:00+01:00 becomes 2025-12-31T23:30:00Z. Conversely, 2026-12-31T23:30:00-01:00 becomes 2027-01-01T00:30:00Z.
- Local service day: 2026-01-01T23:30:00-05:00 with America/New_York and service_date 2026-01-01 passes, even though UTC is 2026-01-02T04:30:00Z. Changing only service_date to 2026-01-02 produces LOCAL_DATE_MISMATCH.
- Spring boundary: 01:59:59-05:00 and 03:00:00-04:00 on March 8 pass for New York; both tested 02:30 representations fail the asserted-zone check. The two valid boundary instants are one second apart in UTC.
- Locale and unknown-date boundary: both 03/04/2026 10:00 and 04/03/2026 10:00 fail TIMESTAMP_FORMAT. So do a date-only value and TBD. The validator never fills in a missing or unknown date.
- Calendar and type boundary: February 29, 2024 passes; February 29, 2026 fails RANGE. Hour 24, out-of-range offsets and normalization beyond the supported years fail RANGE. Null, a numeric timestamp and a boolean zone fail STRING_REQUIRED.
The complete error catalogue groups failures by the next correction, not by a generic parse failed message:
- OBJECT_REQUIRED, UNKNOWN_FIELD and TIMESTAMP_REQUIRED identify the object shape or missing required field. STRING_REQUIRED identifies a supplied field of the wrong type.
- TIMESTAMP_FORMAT requests the declared whole-second timestamp form. UNKNOWN_OFFSET rejects this application’s -00:00 case. LEAP_SECOND_UNSUPPORTED identifies second 60, while RANGE covers invalid calendar, time, offset and normalized-year values.
- ZONE_NOT_ALLOWED requests one of the two supported zone names. ZONE_OFFSET_MISMATCH requests a wall time and offset consistent with that named zone; it is not a diagnosis that every mismatch is a daylight-saving gap.
- ZONE_REQUIRED identifies a service-date assertion without a zone. SERVICE_DATE_FORMAT requests a real YYYY-MM-DD service date. LOCAL_DATE_MISMATCH identifies a validly formatted date that differs from the named-zone local date.
Three negative controls changed copied output records from rejection to acceptance: the missing spring hour, the wrong local service date and a slash-form locale date. The evaluator detected each changed fixture and returned a failing result. Those controls show that it can catch these specific output defects. They do not establish exhaustive parser correctness or prove that an assistant will recover after receiving an error.
Apply the contract to the booking action
In the fictional repair-booking case, the proposed intervention is to give the action a precise timestamp description, enforce the validator in application code, and return a corrective error before any booking write. The date question goes back to the customer if its meaning is unresolved. During the repeated hour, the booking interface should offer distinct, offset-qualified slots rather than an unlabeled 01:30. The local service-day check remains mandatory even when the timestamp parses successfully.
The observable acceptance condition is specific: both declared fold occurrences remain distinct, the two tested spring-gap assertions fail, and the wrong service day cannot pass merely because it matches the UTC date. The local fixture achieved those outputs. The fictional business has not adopted or deployed it, and no booking, native browser invocation or model session was run. Connecting the same checks to the actual booking API and testing its saved schedule would be the next implementation step.
That boundary fits current browser guidance. Chrome’s WebMCP documentation describes tools with input schemas and execution functions, and recommends enforcing binary constraints in code with descriptive errors. Its raw-input guidance also cautions against asking a model to transform strings or do calculations. A strict action contract can coexist with a separate clarification or slot-selection interface; it need not turn unresolved customer wording directly into a timestamp. WebMCP remains a Draft Community Group Report, not a W3C Standard, and the Python replay establishes no native browser support.
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in WebMCP Made Simple Complete Edition, Chapter 09, The Eight-Step Tracking Framework: “If you publish tools for AI assistants but never measure how the assistants use them, you cannot tell whether the work was worth doing.” They also co-authored The Discovery Reset. For the booking case, the practical consequence is to distinguish a format rejection, an asserted-zone mismatch and a completed booking in subsequent measurement. A passing parser result alone is not a completed business task.
ScaleGrowth’s AgenticReadiness audit systems and WebMCP implementation and consulting are relevant when a business needs to inventory date-sensitive actions and define their input and error contracts. OGOS, the Organic Growth Operating System, supports on-page requirements and content briefs, where those accepted formats and recovery instructions need consistent wording. These capabilities make the team a relevant candidate for this work; the synthetic demonstration does not establish a proprietary integration or a customer outcome.
Choose the demonstrated contract only where whole-second instants and the stated zone assertions fit the application. Add zones, fractional precision or recurring-local-time semantics only after defining their expected behavior and extending the fixtures. For the repair-booking example, the decisive requirement is not accepting more date strings. It is refusing to turn an unknown date, a nonexistent local hour or the wrong service day into an appointment.
References
RFC 3339
https://www.rfc-editor.org/rfc/rfc3339
RFC 9557
https://www.rfc-editor.org/rfc/rfc9557.html
IANA timezone source
https://data.iana.org/time-zones/tzdb/northamerica
IANA release NEWS
https://data.iana.org/time-zones/tzdb/NEWS
Python3.12 zoneinfo
https://docs.python.org/3.12/library/zoneinfo.html
WebMCP draft
https://webmachinelearning.github.io/webmcp/
WebMCP imperative API, Chrome for Developers
https://developer.chrome.com/docs/ai/webmcp/imperative-api
Chrome WebMCP best practices
https://developer.chrome.com/docs/ai/webmcp/best-practices
Chrome DevTools WebMCP
https://developer.chrome.com/docs/devtools/application/webmcp
Owned implementation baseline
https://scalegrowth.digital/webmcp-implementation-guide/
WebMCP Implementation, ScaleGrowth Digital
https://scalegrowth.digital/services/webmcp/