All day events possibly wrong

[chipschap]

When importing from Google Calendar, all day events for me are showing up a day early, for instance a Nov 18 all-day event comes out in org-mode as Nov 17. I made this change to fix it:

               else:  # all day event
                    fh_w.write(u"  {}--{}\n".format(

orgDate(comp_start, self.tz),

orgDate(comp_end - timedelta(days=1), self.tz)))

                        orgDate(comp_start + timedelta(days=1), self.tz),
                        orgDate(comp_end, self.tz)))

The reason is that Google calendar lists an all-day event with the previous day as the start time and the actual day as the end time. I don't know if other calendars do the same, so my patch might not be valid universally. However it's a possible fix for users of Google calendar (only). This should also work for multi-day events.

[asoroa]

Hi,
I can't reproduce this. Here is an example of an all-day event for next tuesday nov 5. The event is created in google calendar, and as you can see the DTSTART/DTEND fields are correct (the event starts on nov 5 and ends on nov 6):

BEGIN:VEVENT
DTSTART;VALUE=DATE:20191105
DTEND;VALUE=DATE:20191106
DTSTAMP:20191102T181729Z
UID:4ou73anjghlkhp9v443pmua2nr@google.com
CREATED:20191102T181546Z
DESCRIPTION:
LAST-MODIFIED:20191102T181546Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:All day event on tuesday Nov 5.
TRANSP:TRANSPARENT
END:VEVENT

[chipschap]

asoroa <notifications@github.com> writes:

I can't reproduce this. Here is an example of an all-day event for

Thank you very much for looking into this. But without the patch I made, I will get the wrong date! However the situation may be more complex than I originally thought. There are two other factors: 1. My extreme timezone (GMT-10). 2. I am not doing a direct ical export, I am using the "secret address in ical format" that gcal provides. It is clear that I will have to define the problem much more closely. I would suggest you close my issue, and I will reopen it if I can come up with something definitive and reproducible. Again, many thanks,

…

-- Bob Newell Honolulu, Hawai`i - Via Gnus/BBDB/Org/Emacs/Linux

[chipschap]

Aloha, I don't wish to annoy you further but I do believe I have a genuine solution. The first time around I misread the ical export but the problem was still real. Here is what is happening. gcal converts everything to UTC. But an all day event starts at 00:00 ends at 00:00. But no time zone conversion is made of clock time for an all-day event. So an event for, say, September 17 in my time zone (UTC-10) is listed as starting on Sep 17 at 0000 and ending on Sep 18 at 0000, UTC. This is not really correct but that's on Google. And they might well say that it's their convention. But ical2orgpy does a time zone conversion on these entries. The bottom line is that if you are in UTC or UTC+x time zones, all is well. But in a UTC-xx time zone the date gets shifted back one day. So I suggest the code be made to look like this, which works for me and I suspect for everyone. else: # all day event fh_w.write(u" {}--{}\n".format( orgDate(comp_start, timezone('UTC')), orgDate(comp_end - timedelta(days=1), timezone('UTC')))) In other words, leave the time zone as UTC because gcal (incorrectly, though you could argue the point) lists it as such, although the one upside is that the international date line does not become a factor. Thank you for your time,

…

-- Bob Newell Honolulu, Hawai`i - Via Gnus/BBDB/Org/Emacs/Linux

[asoroa]

Hi again,
(sorry for taking so long).
Your explanation makes a lot of sense. I've merged your change in the repo.
Thanks for digging into it and coming out with the solution!