Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue 27 #565

Merged
merged 37 commits into from
Oct 2, 2023
Merged

Issue 27 #565

merged 37 commits into from
Oct 2, 2023

Conversation

jacadzaca
Copy link
Collaborator

No description provided.

niccokunzmann and others added 30 commits August 30, 2023 16:53
Check that event is included in parsing
updated about.rst to include details that the repo is not obsolete and  still compliant with RFC5545
Exposed by running in `python3 -b` mode.
Fix `vText.__repr__` `BytesWarning`
- did not reference self at all
- keeps compatibility with existing code
- makes testing easier

Signed-off-by: Felix Stupp <felix.stupp@banananet.work>
Signed-off-by: Felix Stupp <felix.stupp@banananet.work>
Signed-off-by: Felix Stupp <felix.stupp@banananet.work>
Signed-off-by: Felix Stupp <felix.stupp@banananet.work>
Component._encode: merge instead of ignore parameters on natives
jacadzaca and others added 6 commits September 26, 2023 20:32
Previously the start and end datetimes were always printed out in the
timezone that they appear in the calendar entry.

In 7a8d584 duration support was added and an attempt was already made
to display the datetime in the local timezone. Unfortunately in that
specific case the `start.astimezone(start.tzinfo)` is a no-op and does
absolutely nothing. Unlike the name suggests, `astimezone()` adjusts the
date and time data, such that they match the passed tzinfo, but since
that is the same timezone data as before, nothing changes. [0]

In order to properly convert to the user's local timezone, we need to
call the method with no arguments.

With this the timezone is always properly displayed, which makes up for
a much nicer UX for users of the cli.

The test has to be adapted to expect the datetime in the local timezone,
hence we cannot hardcode the entire expected string anymore.

[0] https://docs.python.org/3/library/datetime.html#datetime.datetime.astimezone
@niccokunzmann
Copy link
Member

Hm. Somehow, I do not really know what has changed... I will have a look.....

Copy link
Member

@niccokunzmann niccokunzmann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, I found it in the last commits!

@niccokunzmann niccokunzmann merged commit 4cb7b12 into collective:issue-27 Oct 2, 2023
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants