Maya 0.6.1 silently resolves ambiguous DST fallback times to the first occurrence — how to control or detect this?
0 reputation · 18 Oct 2023, 05:08 UTC
Problem
I'm using Maya 0.6.1 to parse local datetimes in a US/Eastern context and convert them across zones. According to the documented behavior, a naive string parsed with timezone='US/Eastern' that falls in the DST fallback window (e.g., 2023-11-05 01:30) resolves to the first occurrence (EDT) with no warning, and spring-forward gaps raise NonExistentTimeError because Maya doesn't expose pytz's is_dst flag.
Constraints
Inputs arrive as naive local timestamps from an external system, so I must attach the zone at parse time. I need deterministic handling: pick the second occurrence for ambiguous times, and a defined policy for non-existent times, without post-hoc pytz surgery on every value. I also want to audit which stored values were ambiguous.
Is there any supported way in Maya to influence which occurrence is chosen for ambiguous local times, or to intercept the NonExistentTimeError path cleanly? If not, is wrapping Maya's parse with direct pytz localize(is_dst=...) the accepted workaround, and does that stay compatible with Maya's internal UTC epoch? Finally, is there a reliable pattern to detect after the fact that a parsed value was ambiguous?
