Proposal: New `<date>` element for Unix timestamps with calendar integration

[stardraw-fred]

What problem are you trying to solve?

Problem

Current <time> element handles dates but lacks native support for Unix timestamps, automatic locale/timezone rendering, or direct calendar event creation. Developers often use JavaScript for these, leading to inconsistencies and accessibility issues.

Use Cases

• Displaying event timestamps (e.g., blog posts, APIs) in user's local format.
• One-click calendar adds for events (e.g., conference schedules, reminders).
• Geo-aware events with optional location data for better integration.
• Relative time for visually impaired

What solutions exist today?

Many open source Javascript libraries, in various states of completeness and disrepair.

How would you solve it?

Proposed Solution

Introduce <date> element:

• Content: Unix timestamp (integer seconds since epoch).
• Rendering: Browser displays as formatted date/time in user's locale/timezone.
• Behavior: Click triggers permission-gated calendar app integration to create event (pre-populated with timestamp, name, duration, location).
• Accessible: TTS renders it in natural language, e.g. "Next Tuesday at 4pm our time"

Syntax

<date>1761582173</date>  <!-- Renders as local date/time -->

<date name="Team Meeting" duration="3600" tz="America/New_York" lat="40.7128" lon="-74.0060" when="1761582173">Monday, October 27, 2025</date>

Attributes

Attribute	Type	Description	Default
name	string	Event title.	None (use timestamp label)
duration	integer	Event length in seconds.	0 (instant)
tz	string	Event timezone (IANA).	UTC
lat	number	Latitude (decimal degrees, -90 to 90).	None
lon	number	Longitude (decimal degrees, -180 to 180).	None
when	integer	Unix timestamp (overrides content).	Content value
parts	string	any combination of Y Q M W D h m s	YMDhm

If the when attribute is present then the browser will use that value instead of the tag's content. Older browsers will ignore the when and instead display the content unmodified. This allows gracful fallback.

If the name attribute is omitted then the browser will NOT integrate with the calendar on click.

If the tz is present then the browser SHOULD on hover present the time relative to the requested time zone in a tooltip/hovertext.

Anything else?

Accessibility/Security

• ARIA fallback to formatted text.
• User prompt for calendar access (e.g., "Add to calendar?"). User should be allowed to configure this; 1. never even ask, 2. always ask, 3. always just do
• Fallback to download .ics if no integration.
• If a tz attribute is present, render the specified timestamp in the tz time zone (not the user's own local one) and make it clear, e.g. "tomorrow at 4pm Pacific Daylight Time"

Implementation Notes

• Parse content as Date object.
• Use Intl.DateTimeFormat for rendering.
• Integrate with Web Calendar API.

Feedback welcome!