If Script's timezone is different than calendar, all day events are created on the wrong day

[derekantrican]

Setup:

Calendar timezone: Central time - Chicago
Script timezone: Pacific Time
Test string (wiki):

var sourceCalendarString =
"BEGIN:VCALENDAR\n"+
"PRODID;X-RICAL-TZSOURCE=TZINFO:-//com.denhaven2/NONSGML ri_cal gem//EN\n"+
"CALSCALE:GREGORIAN\n"+
"VERSION:2.0\n"+
"METHOD:PUBLISH\n"+
"BEGIN:VTIMEZONE\n"+
"TZID;X-RICAL-TZSOURCE=TZINFO:America/Chicago\n"+
"BEGIN:STANDARD\n"+
"DTSTART:20181104T020000\n"+
"RDATE:20181104T020000\n"+
"TZOFFSETFROM:-0500\n"+
"TZOFFSETTO:-0600\n"+
"TZNAME:CST\n"+
"END:STANDARD\n"+
"BEGIN:DAYLIGHT\n"+
"DTSTART:20190310T020000\n"+
"RDATE:20190310T020000\n"+
"TZOFFSETFROM:-0600\n"+
"TZOFFSETTO:-0500\n"+
"TZNAME:CDT\n"+
"END:DAYLIGHT\n"+
"END:VTIMEZONE\n"+
"BEGIN:VEVENT\n"+
"DTEND;VALUE=DATE:20190408\n"+
"DTSTART;VALUE=DATE:20190407\n"+
"DTSTAMP;VALUE=DATE-TIME:20190221T204949Z\n"+
"UID:event_448196497_ngin.com\n"+
"DESCRIPTION:Tag(s): 14U Mascheri\nhttps://sportsengine.page.link/?al=spor\n"+
" tsengine%3A%2F%2Fevent%2F448196497%3Fevent_start_time%3D2019-04-07T05%25\n"+
" 3A00%253A00Z%26team_ids%255B%255D%3D2830426&apn=com.sportngin.android&ct\n"+
" =iCalEventLink&ibi=com.ngin.sport.iphone&isi=499597400&link=http%3A%2F%2\n"+
" Fwww.lakecountystars.org%2Fevent%2Fshow%2F448196497%3Fresource_id%3D4481\n"+
" 96497%26start_time%3D2019-04-07T05%253A00%253A00Z%26team_ids%255B%255D%3\n"+
" D2830426%26type%3Devent&pt=319609&utm_campaign=iCalEventLink\n"+
"SUMMARY:14U Mascheri - Picture Day (time is TBD)\n"+
"LOCATION:\n"+
"END:VEVENT\n"+
"END:VCALENDAR";

Note how event in ics is set for April 7th, but is created on April 6th. If the Script timezone is changed to match the calendar (eg Central Time) then the issue disappears. We should make this rely on the calendar or ics timezone - not the Script timezone

[michaelcadilhac]

Additionally (though probably unrelated), it seems that if the script is to create the calendar, it's set to GMT, making the events appear shifted. This may be fixed by using CalendarApp.setTimeZone on creation, not entirely sure. Changing the timezone after the events are created seems to have no impact.

Edit: Damn it. It worked for 5 minutes then reverted to having everything shifted… Investigating.

[jonas0b1011001]

Easiest fix should be editing the toJSDate function in ical.js to return a Date instead of DateTime for AllDay-Events.

toJSDate: function toJSDate() {
      if (this.zone == ICAL.Timezone.localTimezone) {
        if (this.isDate) {
          return new Date(this.year, this.month - 1, this.day);
        } else {
          return new Date(this.year, this.month - 1, this.day,
                          this.hour, this.minute, this.second, 0);
        }
      } else {
        if (this.isDate) {
          return new Date(this.year, this.month - 1, this.day);
        } else {
          return new Date(this.toUnixTime() * 1000);
        }
      }
    }

[atencza-godaddy]

seeing incorrect timezone on an hour long meeting as well. script runs in same timezone as my calendar. although owner of the original event may be in another timezone, so it's possibly not converting the ical timezone to my timezone properly....

DTSTART;TZID=Central Standard Time:20190711T130000
DTEND;TZID=Central Standard Time:20190711T140000

my script and calendar are in arizona/phoenix timezone, not central standard. it syncs as 1-2pm on my calendar, but it should be 11am-12pm

[bearded22]

I'm encountering a similar problem for events as @amytencza. Events that have been created in a different time zone end up at the wrong location in my calendar. Event is created in India and should apprear at 11:00 but it appears at 14:30.

When I check the logs I see the following:
05:30:00 GMT-0700 but India should be at GMT-5.5. It is showing at the right time in the original calendar, so the problem happens in the sync somewhere.

[derekantrican]

Fixed with #51 . Will release a new version soon

[michaelcadilhac]

I believe the title of this bug report is still not fixed, at least. If I don't set the script's timezone to the ICS's, then events are placed at the wrong time.

[derekantrican]

Ok, I'll reopen this so we make sure to check it

[jonas0b1011001]

I believe the title of this bug report is still not fixed, at least. If I don't set the script's timezone to the ICS's, then events are placed at the wrong time.

Do you have a setup where the event in post 1 is created on the wrong day? Can't reproduce the issue with the latest commit.

[derekantrican]

The initial comment on this issue should have a setup that shows the issue

[michaelcadilhac]

Sure thing. I had the script on BST and this ical:

BEGIN:VCALENDAR
VERSION:2.0
X-WR-CALNAME:OrgMode Calendar
X-WR-TIMEZONE:America/Chicago
BEGIN:VTIMEZONE
TZID:America/Chicago
END:VTIMEZONE
BEGIN:VEVENT
UID:TS1-9ef8856e-5c34-4d40-a13b-4f702d0c5c76
DTSTART:20190910T110000
DTEND:20190910T130000
SUMMARY:My Test at 11am
END:VEVENT
END:VCALENDAR

The log then says that the event is at 11 BST, instead of central time. This is still true if:

• The target calendar is in UTC/BST/CST
• The TZID is "America/Chicago" or "CST"
• The VTIMEZONE section is fully fledged.

[jonas0b1011001]

I don't think that the ics you provided is valid.

1. VTimezone is missing UTC-Offsets
2. DTSTART and DTEND have no tzid property assigned, therefore they are interpreted as floating

After fixing these, it actually worked fine:

var newSrc = "BEGIN:VCALENDAR\n" +
"VERSION:2.0\n" +
"X-WR-CALNAME:OrgMode Calendar\n" +
"X-WR-TIMEZONE:America/Chicago\n" +
"BEGIN:VTIMEZONE\n"+
"TZID;X-RICAL-TZSOURCE=TZINFO:America/Chicago\n"+
"BEGIN:STANDARD\n"+
"DTSTART:20181104T020000\n"+
"RDATE:20181104T020000\n"+
"TZOFFSETFROM:-0500\n"+
"TZOFFSETTO:-0600\n"+
"TZNAME:CST\n"+
"END:STANDARD\n"+
"BEGIN:DAYLIGHT\n"+
"DTSTART:20190310T020000\n"+
"RDATE:20190310T020000\n"+
"TZOFFSETFROM:-0600\n"+
"TZOFFSETTO:-0500\n"+
"TZNAME:CDT\n"+
"END:DAYLIGHT\n"+
"END:VTIMEZONE\n"+
"BEGIN:VEVENT\n" +
"UID:TS1-9ef8856e-5c34-4d40-a13b-4f702d0c5c76\n" +
"DTSTART;TZID=America/Chicago:20190910T110000\n" +
"DTEND;TZID=America/Chicago:20190910T130000\n" +
"SUMMARY:My Test at 11am\n" +
"END:VEVENT\n" +
"END:VCALENDAR\n";

[derekantrican]

@jonas0b1011001 I think some services (maybe Outlook & Google Calendar) might have those values hardcoded for IANA timezones like America/Chicago

[jonas0b1011001]

That might be the case, nevertheless it's not valid and i'm not sure how we would be able to compensate the missing information.

One of 'standardc' or 'daylightc' MUST occur and each MAY occur more than once.

[michaelcadilhac]

I did mention that a fully fledged VTIMEZONE does not solve the problem, but I wasn't aware of the notion of floating time. As per the iCalendar specification:

The use of local time in a DATE-TIME value without the TZID property parameter is to be interpreted as floating time, regardless of the existence of "VTIMEZONE" calendar components in the iCalendar object.

I was wrongly expecting that the VTIMEZONE would apply.

It can however be argued that the right behavior is to use the target calendar timezone rather than the script's; I would expect users to understand the concept of calendar timezone better than script timezone. Depending on how you feel about that, please close this issue or leave it open.

For information, this ics was produced by org-mode, which certainly approximates the standard.

Sorry for the noise and thanks for the support.

[jonas0b1011001]

It can however be argued that the right behavior is to use the target calendar timezone rather than the script's; I would expect users to understand the concept of calendar timezone better than script timezone. Depending on how you feel about that, please close this issue or leave it open.

Totally agree, will try to adjust it :)

[rdbisme]

Same here:

content snapped for Privacy

The event is created at 23:00 while it should be created at 14:00.
The timezone of the script is GMT+1 (Paris) (Even if it should be GMT+2 Paris)
The timezone of the target calendar is (GMT+02:00) Central European Time - Paris

[jonas0b1011001]

Please manually replace your code.gs with the latest version on this repo and try again. The example you posted syncs fine on my end.

[rdbisme]

@jonas0b1011001 That was it. I had an older version. :) It works as expected.

[derekantrican]

I've pulled in @jonas0b1011001 's PR and any other comments seem to be solved. So I'm going to go ahead and close this issue