search

kidd / org-gcal.el

Org sync with Google Calendar. (active maintained project as of 2019-11-06)
435 stars 47 forks source link

Handling of org-gcal-local-timezone incorrect #164

Open wrn opened 2 years ago

wrn commented 2 years ago

I am very excited to try out org-gcal, and was puzzled that the timestamps for my calendar events are sometimes right, sometimes wrong. With some digging, I found the issue is this:

  1. For unknown reason, Google calendar API does not returns timestamps in consistent timezones. At least that is the case for my family shared calendar (a build in feature by Google). Family calendar timezone is fixed to UTC, although when an event is created, that event is created with default local time zone (US eastern time for me). I verified my events are created correctly in US eastern time. But when org-cal fetch them, for some events, the time is returned in eastern time, but for some other events the time is returned in UTC time (the time itself is always correct, just represented in different time zones)

  2. It becomes a problem for the following function (defun org-gcal--convert-time-to-local-timezone (date-time local-timezone) (if (and date-time local-timezone) (format-time-string "%Y-%m-%dT%H:%M:%S%z" (parse-iso8601-time-string date-time) local-timezone) date-time))

When org-gcal-local-timezone is set to nil, date-time is directly returned, hence sometimes it is wrong (for those in UTC time).

  1. But, if we set org-gcal-local-timezone to my local time zone, it also poses some issues: 1) I found the time zone string is very finicky for format-time-string. For example "America/New York" does not work properly on either Windows or Linux. (current-time-zone) returned from Emacs does not work on Windows but works for Linux. (-14400 "EDT") works on both. Such a pain. 2) When local time zone is set to nil, we have the nice behavior that the time will be automatically set to the time zone for that particular date. Time zone is not only determined by location, but also date, because of day light savings time. For example (note the different time zone in the result): (format-time-string "%Y-%m-%dT%H:%M:%S%z" (parse-iso8601-time-string "2021-09-29T12:15:00-04:00") nil) => "2021-09-29T12:15:00-0400" (format-time-string "%Y-%m-%dT%H:%M:%S%z" (parse-iso8601-time-string "2021-12-29T12:15:00-04:00") nil) => "2021-12-29T11:15:00-0500"

  2. So it seems to me the best option is to change the function org-gcal--convert-time-to-local-timezone to: (defun org-gcal--convert-time-to-local-timezone (date-time local-timezone) (format-time-string "%Y-%m-%dT%H:%M:%S%z" (parse-iso8601-time-string date-time) local-timezone)) This will make the out-of-box default behavior work for 99% of us.

The above was tested on both Windows and Linux, Emacs 26.3.

Thanks for this great package.

telotortium commented 2 years ago

Hi, sorry for not getting back to this. Feel free to submit a PR to fix this - otherwise I'll get to this at some point, but maybe not that soon.

wrn commented 2 years ago

My "fix" is simply the new code I put in here (removed the "if" condition in the original code): (defun org-gcal--convert-time-to-local-timezone (date-time local-timezone) (format-time-string "%Y-%m-%dT%H:%M:%S%z" (parse-iso8601-time-string date-time) local-timezone)) It works for me. But I do not know if that in general is OK for everybody (Seems so, just not completely sure).

megodoonch commented 1 year ago

This fix works for me in the current version -- I just replaced the function definition in org-gcal.el.