The following fails:

def round_in_tz(epoch_sec: int, tz_name: str, freq_spec: str):
  """Round the given epoch timestamp to the nearest pandas time frequency spec in the given timezone."""
  return pd.to_datetime(epoch_sec, unit='s', utc=True).tz_convert(tz_name).floor(freq_spec)

print(round_in_tz(1730610000, "US/Eastern", freq_spec="86400s"))  # works OK
# raises pytz.exceptions.AmbiguousTimeError: Cannot infer dst time from 2024-11-03 01:00:00, try using the 'ambiguous' argument
print(round_in_tz(1730610000, "US/Eastern", freq_spec="300s"))  

1. Is there truly any ambiguity here? I’m aware of DST, but using epoch times avoids any ambiguity, right? Is this a bug in Pandas?
2. What’s the best way to rewrite it? I hacked together the following:

def round_in_tz(epoch_sec: int, tz_name: str, freq_spec: str):
  """Round the given epoch timestamp to the nearest pandas time frequency spec in the given timezone."""
    t = pd.to_datetime(epoch_sec, unit='s', utc=True).tz_convert(tz_name)
    is_dst = bool(t.timetuple().tm_isdst)
    return t.floor(freq_spec, ambiguous=is_dst)

NOTE: We cannot use .floor(freq_spec).tz_convert(tz_name) because it changes the behavior when freq_spec=”86400s”. (I want Midnight US/Eastern, not Midnight UTC.)

I’ve found several previous questions on DST ambiguity, but they all involve truly ambiguous situations (such as parsing a timestamp from a string during the doubly-occurring DST hour.) In contrast, this question uses the epoch timestamp 1730610000, which I would not expect to be ambiguous.