Resolve Local AI Calendar Proposals Before Android Handoff

Direct answer

A model-generated date or time is a proposal, not a resolved instant. Preserve its source text and identify the reference date for phrases such as “tomorrow,” intended zone, fixed-instant versus wall-time meaning, and whether the user meant an all-day date. Do not substitute the device zone for an event elsewhere or turn an incomplete phrase into a precise start time; show missing choices in a draft. iCalendar has distinct valid representations: UTC DATE-TIME ends in Z; a zone-bound local DATE-TIME uses TZID and its VTIMEZONE; a value with neither is floating wall time, not one global instant. Use floating time only when intended. A date-only DATE is not a timed DATE-TIME: preserve the type instead of inventing midnight or provider-specific all-day encoding without checking the target contract. A zoned local time has one valid offset normally, zero in a daylight-saving gap, and two in an overlap. Android ZoneRules.getValidOffsets() exposes this from API 26. ZonedDateTime.of() adjusts gaps forward and picks the earlier overlap offset, but those defaults are not user intent. Ask the user to resolve a nonexistent time or choose the repeated occurrence. Parsing and event-generation policy are separate. RFC 5545 interprets a TZID overlap as its first occurrence and a gap using the pre-gap offset. That file rule does not establish what a person intended by uncertain natural language. Export ICS with the appropriate VTIMEZONE and only a resolved value; otherwise retain an editable draft or omit the time. CalendarContract.Events stores DTSTART/DTEND as UTC epoch milliseconds and EVENT_TIMEZONE separately. Resolve a local time with the selected zone before conversion; local clock digits are not epoch milliseconds. Events has existed since API 14; inserts require DTSTART, EVENT_TIMEZONE and calendar_id, plus DTEND for non-recurring events (or recurrence fields). Its documented allDay=1 contract requires EVENT_TIMEZONE="UTC" and midnight boundaries; preserve the chosen dates and follow the destination rules rather than converting a date through the device zone. ACTION_INSERT with Events.CONTENT_URI and begin/end extras can prefill another app’s editor; launching it does not prove a save. A handler query is preflight only: Android package visibility can filter query results, so a null resolution is not universal proof that no calendar app exists. Handle actual launch failure and do not request calendar-write permission merely to hand off to an editor. Direct CalendarContract writes instead involve permissions, an accessible calendar/account, provider behavior and a save policy. A follow-up provider query also needs its own authorization and reliable event identity; do not match a saved event by guessed title/time alone. Prefilled extras grant neither write authority nor proof of a committed row. A calendar account may sync saved events to a service or another device. Show the destination and let the user review title, date, time, zone, location and invitees; do not send invitations without separate confirmation. Local inference does not mean local-only storage. Keep user authorization distinct from model confidence. Test UTC, zoned and intentional floating times, DATE, a gap, both overlap occurrences, missing reference date, a zone different from the device, transition-crossing end time, malformed output, correction and cancellation. Verify ICS serialization, epoch conversion and Android handoff separately. Record the reference context and actual calendar outcome. This is a general method, not a claim Cove currently creates calendar events.

A local assistant proposes a meeting during a repeated hour

A synthetic test uses “tomorrow at 1:30 near the station” with a reference date and event zone deliberately chosen so that 1:30 occurs twice in an overlap. The phone is in another zone. This is a fixture, not a claim that tomorrow at the reader’s location has a transition.

Decision

Preserve the original text, resolve the event location’s zone from reviewed context, detect both valid offsets, and ask which occurrence the user intends before creating a calendar handoff.

Expected outcome

The editor receives a specific, reviewable event proposal or an unresolved draft; neither the device zone nor a library default silently chooses the event instant.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Source and reference-context fixtures
• UTC, floating, TZID and transition decisions
• Epoch mapping and actual editor/provider outcomes

Task quality needs a versioned corpus and acceptance rules. Fluent sample output is not an accuracy result.

Implementation workflow

1. Keep source and reference context. Store the user phrase, reference date/time, locale, event location, and selected zone. Relative dates need a reference point; do not infer one from model confidence.
2. Choose the temporal value type. Classify date-only, UTC instant, zone-bound local DATE-TIME, or intentionally floating wall time. Keep RFC 5545 parsing rules separate from the application’s policy for generating a new appointment.
3. Resolve zone transitions explicitly. Use ZoneRules.getValidOffsets for the selected zone and local time: one offset is ordinary, zero is a gap, and two are an overlap. Ask the user to resolve a gap or choose an overlap occurrence rather than silently applying a library default.
4. Map only resolved instants to Android fields. Convert a confirmed zoned value to epoch milliseconds for CalendarContract DTSTART/DTEND and retain EVENT_TIMEZONE. Treat all-day DATE values separately; verify the target provider’s constraints before encoding them.
5. Hand off for review and test outcomes. Use ACTION_INSERT only as a prefilled editor handoff, or follow a separately authorized direct-provider flow. Test saved, edited, cancelled, unavailable-handler, sync-account, and invitee cases; a launched editor is not a saved-event receipt.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• Every resolved event time is traceable to source text, reference date, intended zone, and an explicit floating-versus-fixed-time decision.
• ZoneRules gaps and overlaps are surfaced for user or documented product resolution; a parser or ZonedDateTime default is not treated as user intent.
• RFC 5545 DATE/DATE-TIME/UTC/TZID/floating values are serialized according to their distinct meanings, while Android timed fields use resolved epoch milliseconds and an explicit time zone.
• Calendar launch, user save, direct provider write, account sync, and invitation are distinct states; no event or external action is claimed complete without evidence and consent.

Decision table

Failure patterns to prevent

• Using device timezone as unstated intent
• Equating editor launch with event save
• Assuming a calendar account is local-only

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• FunctionGemma mobile actions
• Android privacy and security
• IETF RFC 5545 — iCalendar DATE, DATE-TIME, TZID and floating-time rules
• Android API — CalendarContract.Events fields and insert requirements
• Android Developers — common intent for adding a calendar event
• Android API — ZoneRules valid offsets, gaps, and overlaps
• Android API — ZonedDateTime default gap and overlap resolution
• Android Developers — package visibility and intent-handler queries

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions