You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We try to provide some support for other timezones. Timezones need to be supported in both location and in time. For instance, certain times of the year SF is in PST and in other times it is in PDT. When calculating a meeting spec from a meeting subscription, this calculation is incorrect if it is done across timezones. pytest tests/logic/meeting_spec_test.py::test_get_meeting_datetime hits this bug and is failing on master.
The text was updated successfully, but these errors were encountered:
We've discussed this issue offline, going to document it here.
The issue is in get_meeting_datetime implementation. It gets the meeting subscription's utc time and converts to the meeting's local time. This is incorrect because it will DST can change the timezone's offset from UTC. The fix would be to get the local time component of the meeting subscription, and create new local datetime for the current week that sets the time component.
You'll need to store meeting subscription datetime as a UTC timestamp, as this will allow you to determine the local time unambiguously (was it PDT or PST at that location at that time).
We try to provide some support for other timezones. Timezones need to be supported in both location and in time. For instance, certain times of the year SF is in PST and in other times it is in PDT. When calculating a meeting spec from a meeting subscription, this calculation is incorrect if it is done across timezones.
pytest tests/logic/meeting_spec_test.py::test_get_meeting_datetime
hits this bug and is failing on master.The text was updated successfully, but these errors were encountered: