Inspect the working example
The workshop occurs on 6 November 2026. English and Hong Kong Chinese use their own readable labels, while both time elements carry the date-only value 2026-11-06. No starting time or time zone is supplied.
| Case | Input or inspection | Result and meaning |
|---|---|---|
| Machine value | Read time.dateTime | 2026-11-06 in both fixtures |
| Readable label | Read the text content | 6 November 2026; no timestamp is asserted |
| Missing instant data | Inspect supplied facts | No time or offset; do not invent midnight UTC |
Follow the browser mechanism
The datetime attribute provides a machine-readable representation while the text content can use reader-friendly wording. A valid date-only string represents a date, not a specific instant. A browser can retain a malformed datetime string in the DOM; attribute presence alone is not validation of that string.
Relative prose is not a valid date serialization
The visible phrase can be meaningful in context, but the same phrase is not valid date syntax for datetime.
<p>Workshop date: <time id="date" datetime="next Friday">Next Friday</time>.</p>The browser retains the raw phrase in dateTime, but it fails the date-only grammar check. The working value passes that check and names a real calendar date.
Try the repair
Can a calendar script safely treat this workshop date as 2026-11-06T00:00:00Z without another rule?
Show the worked answer
No. That adds a time and UTC offset that were never supplied. Keep it date-only until the task defines the intended time and zone.
- Compare readable text and datetime independently.
- Validate the required date format and calendar value; do not rely on DOM retention.