collective / icalendar / 18650027834 / 4

98%

main: 98%

push

github

Fix VALUE parameter handling for date/time properties (#915)

* Fix VALUE parameter handling for date/time properties

The problem: when you add a property with a datetime.date object, the library
wasn't setting VALUE=DATE in the output. This meant other calendar apps might
misinterpret the data.

What changed:
- Python date objects now automatically get VALUE=DATE
- Python time objects now automatically get VALUE=TIME
- The VALUE parameter is respected when parsing iCalendar data
- RDATE/EXDATE always use vDDDLists to properly handle lists

How it works:
Added a helper function that looks at the Python type and figures out what
VALUE parameter should be. The encoding path checks this and auto-sets the
parameter. The decoding path extracts VALUE and uses it to pick the right
parser.

This builds on earlier work by @thet (PR #331) and @stlaz (PR #196).

Fixes #349
Related to #187

* Update CHANGES.rst

Co-authored-by: Steve Piercy <web@stevepiercy.com>

* Update src/icalendar/cal/component.py

Co-authored-by: Steve Piercy <web@stevepiercy.com>

* Update src/icalendar/cal/component.py

Co-authored-by: Steve Piercy <web@stevepiercy.com>

* Update src/icalendar/cal/component.py

Co-authored-by: Steve Piercy <web@stevepiercy.com>

* Update src/icalendar/cal/component.py

Co-authored-by: Steve Piercy <web@stevepiercy.com>

* Update src/icalendar/prop/__init__.py

Co-authored-by: Steve Piercy <web@stevepiercy.com>

* Address Nicco's review: remove .lower() calls and add type hints

* Remove accidentally committed _build directory

* Fix: Keep .lower() where needed for value lookups

Nicco was right that .lower() isn't needed for CaselessDict keys, but we still need it for:
- value_param: it's a string value used for dict lookup, not a key
- name in tuple check: Python tuple membership isn't case-insensitive

* Remove .lower() calls entirely as Nicco suggested

CaselessDict handles case-insensitivity for all dict operations.
Use .upper() for tuple membership ... (continued)

534 of 547 branches covered (97.62%)

Branch coverage included in aggregate %.

8065 of 8257 relevant lines covered (97.67%)

0.98 hits per line