Do all timezone calculations in libical #709
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Some of them fail and that's ok, since I'll be reimplementing the bad code soon!
Function doesn't need to change, but depends on logic that is changing
tintou
approved these changes
Oct 14, 2021
|
Thanks for all of your work on this! |
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #572, possibly others
As discussed in #660, the conversion process from libical to GLib timezones is very brittle. The most visible result is that Windows-style timezones (
Western European Standard Time) are not handled.This PR moves all timezone logic to libical, which should have access to all the necessary information to run timezone conversions properly, regardless of whether the timezone corresponds to a system built-in. I accomplished this by modifying the functions that convert
ICal.TimeandICal.ComponenttoGLib.DateTime.Basically, the change in this PR is converting the timezone in libical before calling
icaltime_to_datetime, instead of converting after in GLib. That's the only subtantive change, really.One restriction is that some of thsee convert to DateTimes in non-local timezones. Since it's not always possible to get a
GLib.TimeZonefor these cases, the timezone in resulting DateTimes isn't guaranteed to be correct. I documented this restriction with emphasis, but it's still not ideal.I added lots of tests to make sure this works as intended. So I'm pretty sure the new/modified functions all work properly, but the question is if there are any clients that need to be fixed. A text search for function calls didn't reveal anything, but in review I'd appreciate some help looking. If there are no weird cases I missed, then the modified functions should be a drop-in replacement.
Sorry for the terrible commit history. It includes some duplicate work from #653. I'd recommend looking at only the changed files for review, and committing using squash for sure.