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

refactor test_issue_237 #418

Merged
merged 5 commits into from
Oct 15, 2022

Conversation

jacadzaca
Copy link
Collaborator

splitting as per #400. Any idea why the tests pass in #400 but not here?

@niccokunzmann niccokunzmann changed the title refacotr test_issue_237 refactor test_issue_237 Oct 3, 2022
@niccokunzmann
Copy link
Member

So, I see this:

AssertionError: assert datetime.datetime(2017, 5, 11, 13, 30) == 
                       datetime.datetime(2017, 5, 11, 13, 30, tzinfo=zoneinfo.ZoneInfo(key='America/Sao_Paulo'))

That is an okay fail - but why is there no time zone in it?

Hm. Maybe a merge of master changes something?
Why would the event contain a time zone? There should be an error, I think.... The time zone has an unknown identifier.
Also: If it is a test refactoring - where are the tests that get deleted like in all the other PRs?

Maybe that helps.. let's find out together!

@jacadzaca
Copy link
Collaborator Author

The TZID property must be specified before use, so we need to parse a whole calendar. Now, we're back to the problem with pytz, to which @niccokunzmann proposed a solution that I'm not sure how to implement

@niccokunzmann
Copy link
Member

expected = datetime.datetime(2017, 5, 11, 13, 30, tzinfo=timezone('America/Sao_Paulo'))

I think, looking at the output:

assert datetime.datetime(2017, 5, 11, 13, 30, tzinfo=<DstTzInfo '(UTC-03:00) Brasília' Brasília standard-1 day, 21:00:00 STD>)
                     == datetime.datetime(2017, 5, 11, 13, 30, tzinfo=<DstTzInfo 'America/Sao_Paulo' LMT-1 day, 20:54:00 STD>)
                                                                                                                ^^^^^

This is the problem one has with pytz: You can not pass a time zone to the datetime. You must call tz.localize on the datetime object as far as I remember. There was an article about why to avoid pytz and this is one of the reasons - it does not (because old) obey how one would want to use the tz object nowadays. The offset is false because that was the offset before UTC alignment of the time zones. - all from memory this one is.

Could you try running localize() on this dt object?

@niccokunzmann
Copy link
Member

I think, my comment there is that I would like to see that icalendar can actually choose a tz implementation and I would like to have all tests run across all different tz implementations.

I would pass it to from_ical(..., timezone=pytz.tzinfo)
Creating an issue ...

@niccokunzmann
Copy link
Member

@jacadzaca can you merge master again into this one? I can not merge it, yet and I am too tired to resolve the conflict.

@niccokunzmann niccokunzmann merged commit 0e5b092 into collective:master Oct 15, 2022
@niccokunzmann
Copy link
Member

niccokunzmann commented Oct 15, 2022

@jacadzaca Thanks for working together on this one!

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.

2 participants