Skip to content

Bump whenever from 0.8.6 to 0.9.3#284

Open
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/uv/whenever-0.9.3
Open

Bump whenever from 0.8.6 to 0.9.3#284
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/uv/whenever-0.9.3

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Oct 20, 2025

Copy link
Copy Markdown
Contributor

Bumps whenever from 0.8.6 to 0.9.3.

Release notes

Sourced from whenever's releases.

0.9.3

Fixed incorrect offsets for some timezones before the start of their first recorded transition (typically pre-1950) (#296)

0.9.2

Methods that take an int, float, or str now also accept subclasses of these types. This is consistent with the behavior of the standard library and improves compatibility with libraries like numpy and pandas (#260)

0.9.1

Added ZonedDateTime.now_in_system_tz() and ZonedDateTime.from_system_tz() as convenience methods to ease migration away from SystemDateTime.

0.9.0

Breaking Changes

  • SystemDateTime has been removed and merged into ZonedDateTime

    To create a more consistent and intuitive API, the SystemDateTime class has been removed. Its functionality is now fully integrated into an enhanced ZonedDateTime, which now serves as the single, canonical class for all timezone-aware datetimes, including those based on the system's local timezone.

    Rationale:

    The SystemDateTime class, while useful, created several challenges that compromised the library's consistency and predictability:

    • Inconsistent Behavior: Methods like replace() and add() on a SystemDateTime instance would use the current system timezone definition, not necessarily the one that was active when the instance was created. This could lead to subtle and unpredictable bugs if the system timezone changed during the program's execution.
    • API Division: Despite having nearly identical interfaces, SystemDateTime and ZonedDateTime were not interchangeable. A function expecting a ZonedDateTime could not accept a SystemDateTime, forcing users to write more complex code with Union type hints.
    • Maintenance Overhead: Maintaining two parallel APIs for timezone-aware datetimes led to significant code duplication and a higher maintenance burden.

    This change unifies the API by integrating system timezone support directly into ZonedDateTime, providing a single, consistent way to handle all timezone-aware datetimes. The original use cases for SystemDateTime are fully supported by the improved ZonedDateTime.

    This new, unified approach also provides two major benefits:

    • Performance: Operations on a ZonedDateTime representing a system time are now orders of magnitude faster than they were on the old SystemDateTime.
    • Cross-Platform Consistency: The new whenever.reset_system_tz() function

... (truncated)

Changelog

Sourced from whenever's changelog.

0.9.3 (2025-10-16)

Fixed incorrect offsets for some timezones before the start of their first recorded transition (typically pre-1950) (#296)

0.9.2 (2025-09-29)

Methods that take an int, float, or str now also accept subclasses of these types. This is consistent with the behavior of the standard library and improves compatibility with libraries like numpy and pandas (#260)

0.9.1 (2025-09-28)

Added ZonedDateTime.now_in_system_tz() and ZonedDateTime.from_system_tz() as convenience methods to ease migration away from SystemDateTime.

0.9.0 (2025-09-25)

Breaking Changes

  • SystemDateTime has been removed and merged into ZonedDateTime

    To create a more consistent and intuitive API, the SystemDateTime class has been removed. Its functionality is now fully integrated into an enhanced ZonedDateTime, which now serves as the single, canonical class for all timezone-aware datetimes, including those based on the system's local timezone.

    Rationale:

    The SystemDateTime class, while useful, created several challenges that compromised the library's consistency and predictability:

    • Inconsistent Behavior: Methods like replace() and add() on a SystemDateTime instance would use the current system timezone definition, not necessarily the one that was active when the instance was created. This could lead to subtle and unpredictable bugs if the system timezone changed during the program's execution.
    • API Division: Despite having nearly identical interfaces, SystemDateTime and ZonedDateTime were not interchangeable. A function expecting a ZonedDateTime could not accept a SystemDateTime, forcing users to write more complex code with Union type hints.
    • Maintenance Overhead: Maintaining two parallel APIs for timezone-aware datetimes led to significant code duplication and a higher maintenance burden.

    This change unifies the API by integrating system timezone support directly into ZonedDateTime, providing a single, consistent way to handle all timezone-aware datetimes. The original use cases for SystemDateTime

... (truncated)

Commits
  • 43d851b speed up windows CI build
  • 4ef459c fix incorrect offsets for some tzs before start of first transitions (typical...
  • e8f3318 methods now allow int/float/str subclasses in Rust extension
  • 8297e1a refactor: use cast_allow_subclass for ISO parsing methods across date class...
  • c74c216 Clarify format_iso() in docs
  • 936a147 Add two ZonedDateTime methods to ease SystemDateTime deprecation
  • ae24c7b Deprecate old ISO format/parse methods instead of removing them
  • ffd118f fix system tz when /etc/localtime points to zoneinfo.default path
  • 844ac1a Turn rust panics into Python RuntimeError instead of crashing
  • 1a8810f prepare release candidate
  • Additional commits viewable in compare view

Dependabot compatibility score

You can trigger a rebase of this PR by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Note
Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

Bumps [whenever](https://github.com/ariebovenberg/whenever) from 0.8.6 to 0.9.3.
- [Release notes](https://github.com/ariebovenberg/whenever/releases)
- [Changelog](https://github.com/ariebovenberg/whenever/blob/main/CHANGELOG.md)
- [Commits](ariebovenberg/whenever@0.8.6...0.9.3)

---
updated-dependencies:
- dependency-name: whenever
  dependency-version: 0.9.3
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added dependencies python:uv Pull requests that update Python:uv code labels Oct 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies python:uv Pull requests that update Python:uv code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant