build(deps): bump icalendar from 7.1.1 to 7.3.0 in /tools/base

[dependabot]

Bumps icalendar from 7.1.1 to 7.3.0.

Release notes

Sourced from icalendar's releases.

v7.3.0

To view the changes, please see the Changelog. This release can be installed from PyPI.

v7.2.2

To view the changes, please see the Changelog. This release can be installed from PyPI.

v7.2.1

To view the changes, please see the Changelog. This release can be installed from PyPI.

v7.2.0

To view the changes, please see the Changelog. This release can be installed from PyPI.

v7.1.3

To view the changes, please see the Changelog. This release can be installed from PyPI.

v7.1.2

To view the changes, please see the Changelog. This release can be installed from PyPI.

Changelog

Sourced from icalendar's changelog.

7.3.0 (2026-08-19)

Removals and deprecations

- :attr:`~icalendar.prop.binary.vBinary.obj` is deprecated in favor of :attr:`~icalendar.prop.binary.vBinary.bytes`. It is retained as a lossy string view of the value for backward compatibility, and will be removed in icalendar 8. The ``test_ical_value_rejects_non_base64_characters`` test was removed because :attr:`vBinary.ical_value <icalendar.prop.binary.vBinary.ical_value>` no longer validates or decodes Base64. @uwezkhan (`Issue [#1356](https://github.com/collective/icalendar/issues/1356) <https://github.com/collective/icalendar/issues/1356>`_)
- `Issue [#1362](https://github.com/collective/icalendar/issues/1362) <https://github.com/collective/icalendar/issues/1362>`_
New features

- Created an :meth:`~cal.journal.Journal.example` method for the :class:`~cal.journal.Journal` component and an :meth:`~cal.free_busy.FreeBusy.example` method for the :class:`~cal.free_busy.FreeBusy` component, added the :rfc:`5545` examples that they load, and documented their usage in both class docstrings. AI assistance: Kiro CLI with the claude-opus-5 model was used to draft this change. @Souptik96 (`Issue [#743](https://github.com/collective/icalendar/issues/743) &lt;https://github.com/collective/icalendar/issues/743&gt;`_)
- Add :meth:`Alarm.new_display() &lt;icalendar.cal.alarm.Alarm.new_display&gt;`, :meth:`Alarm.new_audio() &lt;icalendar.cal.alarm.Alarm.new_audio&gt;`, and :meth:`Alarm.new_email() &lt;icalendar.cal.alarm.Alarm.new_email&gt;` factory methods for creating :rfc:`5545#section-3.6.6` VALARM components. @klouds27 (`Issue [#865](https://github.com/collective/icalendar/issues/865) &lt;https://github.com/collective/icalendar/issues/865&gt;`_)
- :class:`~icalendar.prop.binary.vBinary` now stores the raw ``bytes`` of the value internally, so non-UTF-8 binary data round-trips losslessly. With the release of icalendar 7.1.0, and previous to this bug fix, :attr:`vBinary.ical_value &lt;icalendar.prop.binary.vBinary.ical_value&gt;` Base64-decoded the raw stored bytes and raised :class:`ValueError` for non-Base64 input. :attr:`vBinary.ical_value &lt;icalendar.prop.binary.vBinary.ical_value&gt;` now returns the raw stored bytes instead of Base64-decoding them, and no longer raises :class:`ValueError` for non-Base64 input. @uwezkhan (`Issue [#1356](https://github.com/collective/icalendar/issues/1356) &lt;https://github.com/collective/icalendar/issues/1356&gt;`_)
- Added :attr:`icalendar.prop.binary.vBinary.bytes`, exposing the raw binary value of a BINARY property. @uwezkhan (`Issue [#1356](https://github.com/collective/icalendar/issues/1356) &lt;https://github.com/collective/icalendar/issues/1356&gt;`_)
- Added the :exc:`~icalendar.error.ICalParsingError` exception as a public API for programmatic handling of iCalendar parsing failures. AI assistance: ChatGPT was used to help debug terminal errors encountered during development. @GAUTAMSANSWAL (`Issue [#1536](https://github.com/collective/icalendar/issues/1536) &lt;https://github.com/collective/icalendar/issues/1536&gt;`_)
- Created a script to automatically generate the :mod:`~icalendar.timezone.windows_to_olson` module from the Unicode Consortium's CLDR GitHub repository. Added lxml as a new development dependency. Added the target ``wo`` to the ``Makefile`` to generate the file from the root of the repository with `make wo`. @stevepiercy (`Issue [#1548](https://github.com/collective/icalendar/issues/1548) &lt;https://github.com/collective/icalendar/issues/1548&gt;`_)
- Added :attr:`vBinary.base64data &lt;icalendar.prop.binary.vBinary.base64data&gt;`, a getter/setter for the Base64 string view of a BINARY property's value, so callers no longer need to call :func:`base64.b64encode` or :func:`base64.b64decode` manually. @gagana2023 (`Issue [#1550](https://github.com/collective/icalendar/issues/1550) &lt;https://github.com/collective/icalendar/issues/1550&gt;`_)
- Added :attr:`Alarm.ACTION &lt;icalendar.cal.alarm.Alarm.ACTION&gt;` and :attr:`AlarmTime.action &lt;icalendar.alarms.AlarmTime.action&gt;` access to the :rfc:`5545#section-3.8.6.1` ``ACTION`` property. I used OpenAI Codex with GPT-5 to assist with this change, then reviewed and tested the result. @bm1016bm-svg (`Issue [#1569](https://github.com/collective/icalendar/issues/1569) &lt;https://github.com/collective/icalendar/issues/1569&gt;`_)
- Record the exact CLDR commit used to generate the Windows-to-Olson timezone mapping and fetch the mapping from that pinned revision. I used AI to assist me with this change. @patrickswedish (`Issue [#1575](https://github.com/collective/icalendar/issues/1575) &lt;https://github.com/collective/icalendar/issues/1575&gt;`_)
- Used :meth:`vBinary.from_ical() &lt;icalendar.prop.binary.vBinary.from_ical&gt;` in :attr:`Image.data &lt;icalendar.prop.image.Image.data&gt;` for consistent Base64 validation, removing the manual :func:`base64.b64decode` call. @klouds27 (`Issue [#1638](https://github.com/collective/icalendar/issues/1638) &lt;https://github.com/collective/icalendar/issues/1638&gt;`_)
- Added :attr:`REQUEST_STATUS` property to :class:`~icalendar.event.Event`, :class:`~icalendar.todo.Todo`, :class:`~icalendar.journal.Journal`, and :class:`~icalendar.free_busy.FreeBusy` with ``request_status`` parameter in ``new()`` constructors per :rfc:`5545#section-3.8.8.3`. I used AI to assist with this change. @SemTiOne (`Issue [#1666](https://github.com/collective/icalendar/issues/1666) &lt;https://github.com/collective/icalendar/issues/1666&gt;`_)
- Improved :exc:`~icalendar.error.ICalParsingError` by including optional value, line, and line number information in exception messages for more consistent iCalendar parsing error reporting. AI assistance: ChatGPT was used to help debug terminal errors encountered during development. @GAUTAMSANSWAL
- Made :exc:`~icalendar.error.JCalParsingError` inherit from :exc:`~icalendar.error.InvalidCalendar` for consistency with :exc:`~icalendar.error.ICalParsingError`. AI assistance: ChatGPT was used to help debug terminal errors encountered during development. @GAUTAMSANSWAL
Bug fixes

- Resolve the timezone of a &amp;quot;globally unique&amp;quot; :rfc:`5545#section-3.2.19` ``TZID`` such as ``/freeassociation.sourceforge.net/Europe/Berlin``, which is emitted by some clients, including libical and Evolution. :meth:`TZP.timezone &amp;lt;icalendar.timezone.tzp.TZP.timezone&amp;gt;` now strips the leading vendor prefix and resolves the trailing Olson identifier, so the value is parsed as timezone-aware instead of being silently treated as naive. Prepared with AI assistance. @vjsai (`Issue [#313](https://github.com/collective/icalendar/issues/313) &amp;lt;https://github.com/collective/icalendar/issues/313&amp;gt;`_)
- Fixed the `equivalent_timezone_ids.py` script after the call to generate the timezone Python code was removed. @gjabell (`Issue [#1392](https://github.com/collective/icalendar/issues/1392) &amp;lt;https://github.com/collective/icalendar/issues/1392&amp;gt;`_)
- Values of unrecognized properties and ``X-`` properties without a ``VALUE`` parameter were altered by escaping when parsed, serialized, or converted to and from jCal, so they did not round-trip unchanged as :rfc:`7265` specifies. These values are now preserved verbatim. Additionally, the ``PROXIMITY`` property (:rfc:`9074`) was treated as an unknown value type instead of ``TEXT`` and is now recognized correctly. AI disclosure: I used Claude Code (Anthropic's Claude Opus) to draft and refine this change and its tests; I reviewed the output and validated the change locally. @lcampanella98 (`Issue [#1445](https://github.com/collective/icalendar/issues/1445) &amp;lt;https://github.com/collective/icalendar/issues/1445&amp;gt;`_)
- Ship :file:`funding.json` in PyPI source distributions so packaging and test runs from the sdist no longer fail with :class:`FileNotFoundError`. @Hishamkhashman1 (`Issue [#1493](https://github.com/collective/icalendar/issues/1493) &amp;lt;https://github.com/collective/icalendar/issues/1493&amp;gt;`_)
- Avoid folding content lines between escape prefixes and their escaped characters. AI disclosure: I used GPT-5 Codex to help draft and refine this change and its tests; I reviewed and validated the output locally. @kingrubic (`Issue [#1501](https://github.com/collective/icalendar/issues/1501) &amp;lt;https://github.com/collective/icalendar/issues/1501&amp;gt;`_)
- Preserve ``URI`` value parameters on a jCal round-trip. :meth:`vUri.from_jcal &amp;lt;icalendar.prop.uri.vUri.from_jcal&amp;gt;` previously passed the parameters positionally, but ``vUri.__new__`` takes ``encoding`` as its second positional parameter. As a result, the ``URI`` value parameters were consumed as ``encoding`` and dropped. For example, ``ATTACH;FMTTYPE=...`` or ``CONFERENCE;FEATURE=...`` lost their parameters. They are now passed as the ``params`` keyword. Prepared with the assistance of an AI coding agent (Anthropic's Claude Opus 4.8). @gaoflow (`Issue [#1526](https://github.com/collective/icalendar/issues/1526) &amp;lt;https://github.com/collective/icalendar/issues/1526&amp;gt;`_)
- Updated the Windows timezone mapping for ``Mountain Standard Time (Mexico)`` to ``America/Mazatlan``, so dates after Mexico's 2022 timezone changes use the correct UTC-7 offset instead of UTC-6. Prepared with AI assistance. @RobHannay (`Issue [#1546](https://github.com/collective/icalendar/issues/1546) &amp;lt;https://github.com/collective/icalendar/issues/1546&amp;gt;`_)
- ``IMAGE`` properties now use their explicitly declared ``VALUE`` type instead of always being parsed as unknown, while ``IMAGE`` without a ``VALUE`` parameter remains unknown. I used OpenAI Codex with GPT-5 to assist with this change. @floze-the-genius (`Issue [#1561](https://github.com/collective/icalendar/issues/1561) &amp;lt;https://github.com/collective/icalendar/issues/1561&amp;gt;`_)
- Removed ``ATTACH`` from :attr:`Alarm.singletons &amp;lt;icalendar.cal.alarm.Alarm.singletons&amp;gt;`. An &amp;quot;email&amp;quot; ``VALARM`` may carry more than one ``ATTACH`` per :rfc:`5545#section-3.6.6`, so ``ATTACH`` belongs in ``multiple`` only; it was previously listed in both ``singletons`` and ``multiple``. Added a regression test that ``singletons`` and ``multiple`` are disjoint for every registered component. Prepared with the assistance of an AI coding agent (Anthropic's Claude Opus 4.8). @vtino17 (`Issue [#1569](https://github.com/collective/icalendar/issues/1569) &amp;lt;https://github.com/collective/icalendar/issues/1569&amp;gt;`_)
- :attr:`Alarm.REPEAT &amp;lt;icalendar.cal.alarm.Alarm.REPEAT&amp;gt;`, :attr:`Alarm.repeat &amp;lt;icalendar.cal.alarm.Alarm.repeat&amp;gt;`, :attr:`Event.sequence &amp;lt;icalendar.cal.event.Event.sequence&amp;gt;`, and :attr:`Event.priority &amp;lt;icalendar.cal.event.Event.priority&amp;gt;` now reject non-integers (including booleans) with :exc:`TypeError` and negative values with :exc:`~icalendar.error.InvalidCalendar`. @heyncth (`Issue [#1594](https://github.com/collective/icalendar/issues/1594) &amp;lt;https://github.com/collective/icalendar/issues/1594&amp;gt;`_)
- Added the missing ``BINARY`` member to :class:`icalendar.enums.VALUE`, per :rfc:`5545#section-3.2.20`. ``VALUE.BINARY`` previously raised ``AttributeError``. Prepared with the assistance of an AI coding agent (Anthropic's Claude Opus 4.8). @vtino17 (`Issue [#1607](https://github.com/collective/icalendar/issues/1607) &amp;lt;https://github.com/collective/icalendar/issues/1607&amp;gt;`_)
- A ``PERIOD`` value written with dates instead of datetimes, such as ``RDATE;VALUE=PERIOD:19970101/19970102``, was accepted when a calendar was parsed and then raised an :exc:`AttributeError` when it was written out again, or a :exc:`TypeError` where only one half was a date. Such a value is now read as midnight, in the timezone of the other half where it has one. I used AI to assist me with this change. @lcampanella98 (`Issue [#1633](https://github.com/collective/icalendar/issues/1633) &amp;lt;https://github.com/collective/icalendar/issues/1633&amp;gt;`_)
- When :func:`icalendar.use_pytz` was in effect, a date parsed with a ``TZID``, such as ``RDATE;TZID=America/New_York;VALUE=DATE:19970101``, was given the timezone's oldest known offset, its local mean time, so the value was minutes off. It is now read with the offset that applied on that date. Calendars read with zoneinfo, the default, were not affected. I used AI to assist me with this change. @lcampanella98 (`Issue [#1633](https://github.com/collective/icalendar/issues/1633) &amp;lt;https://github.com/collective/icalendar/issues/1633&amp;gt;`_)
- Escape a lone ``\r`` as ``\n`` in :func:`icalendar.parser.string._escape_char`, used by :meth:`vText.to_ical &amp;lt;icalendar.prop.text.vText.to_ical&amp;gt;`. A carriage return not followed by a line feed was previously left raw in the serialized content line, so a ``SUMMARY`` or ``DESCRIPTION`` built from untrusted text could carry a control character into the iCalendar stream and split the line for lenient consumers. ``\r\n`` and ``\n`` were already escaped, and the parameter escaper already mapped ``\r`` to ``^n``. @alhudz (`Pull Request [#1462](https://github.com/collective/icalendar/issues/1462) &amp;lt;https://github.com/collective/icalendar/pull/1462&amp;gt;`_)
- Reject non-ASCII digits in the ``ordwk`` part of :class:`~icalendar.prop.recur.weekday.vWeekday` (``BYDAY``, ``BYWEEKDAY``, and ``WKST``). The value validation regular expression ``\d`` matches non-ASCII digits, such as the Arabic-Indic ``١٢``. A value such as ``١٢MO`` was silently accepted as ``relative == 12``, instead of being rejected, as required by :rfc:`5545#section-3.3.10` (``ordwk = 1*2DIGIT``). This mirrors the earlier :class:`~icalendar.prop.recur.month.vMonth` fix. Drafted with AI assistance (Claude Opus 4.8); reviewed, tested, and verified by the author. @Labib-Bin-Salam
- Reject raw CR and LF in :class:`~icalendar.prop.uri.vUri`, :class:`~icalendar.prop.cal_address.vCalAddress`, :class:`~icalendar.prop.inline.vInline`, and :class:`~icalendar.prop.xml_reference.vXmlReference`. These value types are not escaped on serialization, so a lone ``\r`` in the value was written straight into the content line, slipping past the newline-only assertion in ``Contentline`` and reparsing as a separate property. This was reachable from untrusted jCal via ``URL``, ``ATTENDEE``, and ``ORGANIZER``. @alhudz
- jCal property names, parameter names, and ``RRULE`` part names are now validated as lowercase iCalendar tokens when parsing jCal (RFC 7265 sections :rfc:`7265#section-3.4`, :rfc:`7265#section-3.5`, and :rfc:`7265#section-3.6.10`). They were kept verbatim and re-emitted into the content line on serialization, so a name containing ``:``, ``;``, or a lone carriage return could inject parameters or a new content line for consumers that treat a bare ``\r`` as a break. @alhudz


&amp;lt;/tr&amp;gt;&amp;lt;/table&amp;gt; 
&lt;/code&gt;&lt;/pre&gt;
&lt;/blockquote&gt;
&lt;p&gt;... (truncated)&lt;/p&gt;
&lt;/details&gt;
&lt;details&gt;
&lt;summary&gt;Commits&lt;/summary&gt;

&lt;ul&gt;
&lt;li&gt;&lt;a href=&quot;https://github.com/collective/icalendar/commit/138c8453db34fbb584bbcbc592fd7bd4b972e8ef&quot;&gt;&lt;code&gt;138c845&lt;/code&gt;&lt;/a&gt; remove duplicated news fragment&lt;/li&gt;
&lt;li&gt;&lt;a href=&quot;https://github.com/collective/icalendar/commit/933ff2c789dab88e9fde0e249bcdec832dc1e5e4&quot;&gt;&lt;code&gt;933ff2c&lt;/code&gt;&lt;/a&gt; Merge main into 7.x&lt;/li&gt;
&lt;li&gt;&lt;a href=&quot;https://github.com/collective/icalendar/commit/849919f4f6e9de4f684fcc2c391d347bdfada0e8&quot;&gt;&lt;code&gt;849919f&lt;/code&gt;&lt;/a&gt; version 7.3.0&lt;/li&gt;
&lt;li&gt;&lt;a href=&quot;https://github.com/collective/icalendar/commit/8d20a43036fd5acbc5a36f9e885dbdc3267462cd&quot;&gt;&lt;code&gt;8d20a43&lt;/code&gt;&lt;/a&gt; move breaking change to feature (&lt;a href=&quot;https://redirect.github.com/collective/icalendar/issues/1685&quot;&gt;#1685&lt;/a&gt;)&lt;/li&gt;
&lt;li&gt;&lt;a href=&quot;https://github.com/collective/icalendar/commit/bc179116e63a2447adf77de66034bd3d2078b9f3&quot;&gt;&lt;code&gt;bc17911&lt;/code&gt;&lt;/a&gt; [docs] Fix unqualified cross-references in Todo docstrings (&lt;a href=&quot;https://redirect.github.com/collective/icalendar/issues/1678&quot;&gt;#1678&lt;/a&gt;)&lt;/li&gt;
&lt;li&gt;&lt;a href=&quot;https://github.com/collective/icalendar/commit/698624cacf4b48244a82acb3cc60de9cd0f33750&quot;&gt;&lt;code&gt;698624c&lt;/code&gt;&lt;/a&gt; Add REQUEST-STATUS property (&lt;a href=&quot;https://redirect.github.com/collective/icalendar/issues/1672&quot;&gt;#1672&lt;/a&gt;)&lt;/li&gt;
&lt;li&gt;&lt;a href=&quot;https://github.com/collective/icalendar/commit/82b19379a16cea095659efc0f132d3b3b4ad1dba&quot;&gt;&lt;code&gt;82b1937&lt;/code&gt;&lt;/a&gt; Add return type hint to use_default (&lt;a href=&quot;https://redirect.github.com/collective/icalendar/issues/1665&quot;&gt;#1665&lt;/a&gt;)&lt;/li&gt;
&lt;li&gt;&lt;a href=&quot;https://github.com/collective/icalendar/commit/514be871254a99ebbd35b72e9f155afa1f67431e&quot;&gt;&lt;code&gt;514be87&lt;/code&gt;&lt;/a&gt; fix: validate non-negative integer values for repeat, sequence, priority (&lt;a href=&quot;https://redirect.github.com/collective/icalendar/issues/1598&quot;&gt;#1598&lt;/a&gt;)&lt;/li&gt;
&lt;li&gt;&lt;a href=&quot;https://github.com/collective/icalendar/commit/069e672ace766b3ed0db171d5fab5bbf40c3b864&quot;&gt;&lt;code&gt;069e672&lt;/code&gt;&lt;/a&gt; Rename timezone_datetime_property to _timezone_datetime_property (&lt;a href=&quot;https://redirect.github.com/collective/icalendar/issues/1011&quot;&gt;#1011&lt;/a&gt;) (&lt;a href=&quot;https://redirect.github.com/collective/icalendar/issues/1675&quot;&gt;#1675&lt;/a&gt;)&lt;/li&gt;
&lt;li&gt;&lt;a href=&quot;https://github.com/collective/icalendar/commit/b83927513910b6cbe740e8ab52d21c03a004d06a&quot;&gt;&lt;code&gt;b839275&lt;/code&gt;&lt;/a&gt; chore(deps): bump github/codeql-action/upload-sarif from ea14db8afdef5d462e69...&lt;/li&gt;
&lt;li&gt;Additional commits viewable in &lt;a href=&quot;https://github.com/collective/icalendar/compare/v7.1.1...v7.3.0&quot;&gt;compare view&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;/details&gt;

&lt;br /&gt;</code></pre>


[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=icalendar&package-manager=pip&previous-version=7.1.1&new-version=7.3.0)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

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 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)


</details>