set icaltimetype::zone on create/conversion #571
Comments
gnomesysadmins
pushed a commit
to GNOME/evolution
that referenced
this issue
May 11, 2022
Without having set correct time zone for the ICalTime the conversion routines can convert time twice into the destination time zone, which causes wrong time. It could be seen also when comparing the current time with the component time. Related to libical/libical#571
gnomesysadmins
pushed a commit
to GNOME/evolution
that referenced
this issue
May 11, 2022
Without having set correct time zone for the ICalTime the conversion routines can convert time twice into the destination time zone, which causes wrong time. It could be seen also when comparing the current time with the component time. Related to libical/libical#571
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've been fooled with the icaltimetype::zone requirement once again, specifically when comparing two times in different zones. As I want to compare the even time with the current time, I create the
nowasicaltimetype now = icaltime_current_time_with_zone(my_zone);and then I compare it to another icaltimetype, which is in another zone.Problems:
now.zoneis set to UTC, not to themy_zoneicaltime_compare()converts the time to themy_zoneagain, causing wrong time comparison.Having set a wrong
icaltimetype::zoneis not always a problem (like when the converted time is only used to read the values back is okay), only those routines which expect it to be populated properly can misbehave, when the zone is not updated.This patch changes the behaviour, but I do not propose it as a pull request, because it has important side effects, which may or may not be a problem.
It's also possible there are more functions to be updated, to set the
icaltimetype::zoneproperly after conversion.What do you think?
The text was updated successfully, but these errors were encountered: