DST bug?

[petrprikryl]

I found strange outputs. I suspect that this is due DST because the DST shift will be in 2025-10-26.

from zoneinfo import ZoneInfo
from datetime import datetime

prague = ZoneInfo(key='Europe/Prague')
now = datetime(year=2025, month=10, day=19, hour=12, minute=0, second=0, tzinfo=prague)

c = croniter("10 3 * * 0", now)
c.get_prev(datetime)
>>> Out[34]: datetime.datetime(2025, 10, 19, 3, 10, tzinfo=zoneinfo.ZoneInfo(key='Europe/Prague'))
c.get_next(datetime)
>>> Out[35]: datetime.datetime(2025, 10, 26, 4, 10, tzinfo=zoneinfo.ZoneInfo(key='Europe/Prague'))
# Here I would expect 2025-10-19 as interval is 1 week, not 1 hour
c.get_prev(datetime)
>>> Out[36]: datetime.datetime(2025, 10, 26, 3, 10, tzinfo=zoneinfo.ZoneInfo(key='Europe/Prague'))

[vimeh]

Am getting the same issue (note that am using pendulum objects for my tz aware datetimes)

from datetime import datetime

import pendulum
from croniter import croniter

reference = pendulum.parse("2025-11-03 12:00:00", tz="US/Eastern")

cron = croniter("0 0 * * 0", reference)
result = cron.get_prev(datetime) # 2025-11-01 23:00:00-04:00
# expected 2025-11-02 00:00:00-04:00

the workaround I'm currently using is to use naive datetimes, and to let pendulum handle the datetime coercion

cron_fixed = croniter("0 0 * * 0", reference.naive())
result_fixed = pendulum.parse(str(cron_fixed.get_prev(datetime)), tz="US/Eastern")

EDIT: This appears to actually be fixed by f48387b which is in version 6.0.1rc1 and later. So once there's a new release on pypi this should be fixed

[griquelme]

Also experiencing the same issue in EST:

from datetime import datetime
from importlib.metadata import version
from zoneinfo import ZoneInfo

from croniter import croniter

tz = ZoneInfo(key="America/New_York")
prev = datetime(year=2025, month=10, day=31, hour=19, minute=5, second=0, tzinfo=tz)

c = croniter("5 5,19 * * 1-5")
nxt_actual = c.get_next(ret_type=datetime, start_time=prev)
nxt_expected = datetime(year=2025, month=11, day=3, hour=5, minute=5, tzinfo=tz)

print(f"croniter version is {version('croniter')}")
print(f"previous datetime was {prev} ({prev.tzinfo})")
print(f"actual next datetime is {nxt_actual} ({nxt_actual.tzinfo})")
print(f"expected next datetime is {nxt_expected} ({nxt_expected.tzinfo})")

# croniter version is 6.0.0
# previous datetime was 2025-10-31 19:05:00-04:00 (America/New_York)
# actual next datetime is 2025-11-03 06:05:00-05:00 (America/New_York)
# expected next datetime is 2025-11-03 05:05:00-05:00 (America/New_York)

[Safrone]

f48387b does appear to fix this issue. A test I have

would love a pypi release

  def test_schedule_dst_croniter(self):
    """Bug fixed in croniter 6.1.0rc1"""
    schedule = "0 9 8 * *"
    la_tz = ZoneInfo("America/Los_Angeles")
    la_tz_pytz = pytz.timezone("America/Los_Angeles")
    relative_time_pytz = datetime(2025, 10, 8, 9, 0, 0, tzinfo=la_tz_pytz)
    next_date_pytz = croniter(schedule, start_time=relative_time_pytz, ret_type=datetime).get_next(ret_type=datetime)

    relative_time = datetime(2025, 10, 8, 9, 0, 0, tzinfo=la_tz)
    next_date = croniter(schedule, start_time=relative_time, ret_type=datetime).get_next(ret_type=datetime)

    expected_next_date = datetime(2025, 11, 8, 9, 0, 0, tzinfo=la_tz)
    self.assertEqual(next_date_pytz, expected_next_date)
    self.assertEqual(next_date, expected_next_date)