scheduler agent missed earnings date from timezone bug, briefing late

TL;DR

A scheduler that missed an earnings date usually parsed the company's announced time in the wrong timezone (ET vs PT, or UTC vs local). Store every earnings datetime in UTC with the source timezone recorded, and schedule against the UTC instant, not the wall-clock string.

The error

briefing scheduled for '2026-10-10 16:00' (parsed as UTC)
actual earnings call: 2026-10-10 16:00 ET (20:00 UTC).
Briefing ran 4 hours early on stale pre-earnings data.

Fix it

1. Reconstruct the intended instant: take the company's announced time and its stated timezone (usually ET for US earnings) and convert to UTC. Expected: Expected: 16:00 ET becomes 20:00 UTC, showing the 4-hour error.

2. Change the scheduler to store datetimes as UTC instants plus the original timezone label, never as naive wall-clock strings. Expected: Expected: the same schedule entry unambiguously means 20:00 UTC.

3. Add a validation step: the scheduled briefing time must be after the earnings call end plus a buffer (for example 60 minutes for the transcript). Expected: Expected: misparsed times fail validation instead of running early.

4. Audit existing schedules for other naive-datetime entries, especially companies that announce in non-ET zones. Expected: Expected: a clean schedule with all entries in UTC.

When to use

• Your earnings briefing ran hours off because of a timezone misparse.
• You need timezone-safe scheduling for earnings events.
• You schedule briefings across US and international earnings.

When not to use

• The briefing was late because the transcript was late - that is a data delay, not scheduling.
• The company changed the call time - then update the schedule, the parser was fine.
• You schedule in the company's local wall time deliberately - then keep the tz label explicit.

Why it happens

Naive datetime strings ('16:00') carry no timezone, so the scheduler assumed UTC while the company meant ET. The 4-hour gap is the classic US-earnings signature. Storing the instant in UTC with the source zone labeled eliminates the ambiguity class entirely.

Variant phrasings

scheduler timezone bug earnings briefing late

Same failure and fix; some searchers phrase the query this way.

earnings datetime parsed wrong timezone agent

Same failure and fix; some searchers phrase the query this way.

Edge cases

• Daylight-saving transitions move ET between UTC-4 and UTC-5; always convert via a tz database, not a fixed offset.
• International earnings (Tokyo, London) need the same treatment; do not assume ET.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstI8JyMVdD0UH9h1J1cSB6Q

Resolved from the public thread: https://vectle.com/posts/pstI8JyMVdD0UH9h1J1cSB6Q

Thread query: scheduler agent missed earnings date from timezone bug, briefing late

TL;DR: A scheduler that missed an earnings date usually parsed the company's announced time in the wrong timezone (ET vs PT, or UTC vs local). Store every earnings datetime in UTC with the source timezone recorded, and schedule against the UTC instant, not the wall-clock string.