Maya 0.6.1 silently resolves ambiguous DST fallback times to the first occurrence — how to control or detect this?

Short answer

No — Maya 0.6.1 has no supported way to influence which occurrence is chosen for ambiguous local times, and no hook to intercept the NonExistentTimeError path other than catching it. The silent first-occurrence (EDT) resolution you observed is inherited from pytz's localize() default of is_dst=False... wait, the key detail: pytz's localize() defaults to is_dst=False, but Maya's parsing path effectively resolves ambiguous wall times to the first occurrence and offers no parameter to change it. The accepted workaround is exactly what you suspected: localize with pytz directly, then wrap the aware datetime in Maya. That is fully compatible with Maya's internals because Maya stores everything as a UTC epoch anyway.

Why the workaround is safe

A MayaDT is essentially a wrapper around a UTC timestamp. Once a datetime is timezone-aware, Maya only needs its UTC equivalent — it does not care which library produced the awareness. So this round-trips cleanly:

import maya
import pytz
from datetime import datetime

eastern = pytz.timezone('US/Eastern')
naive = datetime(2023, 11, 5, 1, 30)

# Second occurrence (EST) instead of Maya's silent first (EDT)
aware = eastern.localize(naive, is_dst=False)
dt = maya.MayaDT.from_datetime(aware)
print(dt.iso8601())  # 2023-11-05T06:30:00Z, not 05:30:00Z

Verify epoch compatibility on your version with a known instant: compare maya.MayaDT.from_datetime(aware).epoch against aware.timestamp(). They should match.

Deterministic policy for both edge cases

Use is_dst=None, which makes pytz raise on both ambiguous and non-existent times instead of guessing. That gives you one choke point for your policy:

from pytz.exceptions import AmbiguousTimeError, NonExistentTimeError

def parse_local(s, tz):
    naive = datetime.strptime(s, '%Y-%m-%d %H:%M')
    try:
        aware = tz.localize(naive, is_dst=None)
    except AmbiguousTimeError:
        aware = tz.localize(naive, is_dst=False)  # policy: second occurrence
        audit_log(s, 'ambiguous')
    except NonExistentTimeError:
        aware = tz.localize(naive, is_dst=True)   # policy: shift forward
        audit_log(s, 'gap')
    return maya.MayaDT.from_datetime(aware)

This replaces both Maya behaviors you dislike: ambiguity becomes an explicit branch, and the gap no longer escapes as an unhandled Maya exception. Keep the localization on naive datetimes only — calling localize() on an already-aware datetime raises ValueError.

Auditing stored values after the fact

If values are stored as UTC (which Maya encourages), you can detect past ambiguity by reversing the conversion: convert each stored UTC instant back to US/Eastern and check whether its wall time falls inside the fallback window (for US/Eastern, 01:00–02:00 local on the transition date). Any stored value whose local wall time is in that window may have been ambiguous — but note the limitation: you cannot tell from the UTC value alone whether the original input intended the first or second occurrence. Detection after the fact tells you which rows were at risk, not which were wrong. Going forward, the audit_log call above is the only reliable record.

Caveats

Maya is effectively unmaintained, and pytz itself is legacy compared to Python 3.9+'s zoneinfo (which uses a fold attribute instead of is_dst). If this pipeline is long-lived, consider whether Maya is earning its place versus plain zoneinfo datetimes. Also confirm the exact transition-window behavior against your installed pytz version's tzdata, since transition dates are data-driven, not hardcoded.