class times not exporting properly

[MKinney83]

imported icalendar from custom schedule (tried CSV google said: "Failed to import events: Unable to process your iCal/CSV file." ical worked as far as importing dates but times are at least almost all off (not sure EVERY one is) showing things taking place hours early some as early as 5/530 am with no rhyme or reason. I can and am editing times one by one but kinda defeats the point of importing a calendar.

[yolksinger]

I intended to report this also. Seems to be related to using UTC/GMT in the .ics export. I only have old versions of iCal, but setting Time Zone support to 'On' I can select Eastern Time (-4:00) for each event instead of UTC/GMT. All times are 4 hours earlier when imported. Importing into Google Calendar, I can set my user-wide prefs (not individual calendar - doesn't seem to help) to UK location and 'GMT -0:00 (no DST)' and everything is fine. Otherwise it's the same 4 hours early.

[yolksinger]

FWIW, the behavior is the same when subscribing in iCal or 'Add by URL' in Google Calendar. (I'd never had this working because I didn't realize my custom schedule needs to be publicly accessible.) In Google Calendar, the subscribed calendar ('Add by URL') shows the timezone as GMT and can't be changed. I wonder if this was adopted because of some recommendation for .ics files (more flexibility) but I think that approach is only useful for personal events which need to be the same hour in various time zones. It seems to be mentioned frequently as a problem for travelers entering their agenda at home and using the new time zone at destination. In order to use GMT for the .ics export, all times would have to be offset by +04:00 to be correct at Pennsic.

[rowenamoore2017]

I have run into this issue too and it's June 11. Is there a resolution for this issue or a fix?

[yolksinger]

I have managed to edit the iCal file to correct the problem, though I didn't know anything about the iCal parameters for timezone. It's possible it could cause some other problem for some users, but it works for me. Also, obviously it only helps if you don't need to subscribe for updates.

I removed the letter 'Z' from the end of all start and end times. Possibly this difference is only necessary for older iCal versions. I opened the .ics file in a text editor and used a find and replace on '00Z' to '00'. This seems to do the trick without causing any problems, but I didn't carefully check what other parameters are affected.

[yolksinger]

Oops, I just found that the X-WR-TIMEZONE:US/Eastern line wasn't necessary. Killing off the letter 'Z' in DTSTART and DTEND lines was the fix. Edited previous comment.

[skandragon]

Does killing the timezone and removing the lock-down to UTC fix this?

My thought was I had to include the time zone so when you are in Eastern, it will use the correct time zone rather than when it was added. Without this, I would add them in Central, and when I get on site, they are all an hour off.

[MKinney83]

Still off. Ical cant edit if you meant us to and .csv is still unreadable by at least google (didnt check with outlook this time as if it does load but has wrong times erasing events in outlook is a pita)

[yolksinger]

skandragon, I'm not sure if you mean you've changed the output to be "killing the timezone and removing the lock-down to UTC" now. My own edits (in TextEdit) were stab-in-the-dark attempts after trying to find info on iCal TZ parameters. Just now I was comparing previously saved .ics files from 43, 44, and 45 to the current output and noticed the only differences are the block of ten lines beginning 'BEGIN:VTIMEZONE' in older output is absent in the current output, and that DTSTART and DTEND paramenters did not have 'Z' at the end of the line in the old files. I see no effect from adding the 'BEGIN:VTIMEZONE' block, but removing all the Zs corrected it. What function do the Z characters serve?

Are most iCal users not having this issue? The latest iCal I tested it on is version 6. Doesn't make a difference if Time Zone Support is on or not.

Google Calendar sees my subscribed (Add by URL) custom calendar time zone as '(GMT+00:00) UTC'. This seems significant.

Timezone issues seem to be a long-standing confusion for iCal users. I haven't used it that much, but I can say that in previous years this worked without issue. But I'm already in Eastern time zone, if that matters.

[MKinney83]

I am also in EST but it being several hours off I think there is more than a time zone location issue if skandragon is in central. But then I'm not well versed in this whole thing as Pennsic is the only thing I have enough things to do at certain times using a calendar is worth it

[mcavalletto]

The ICS files being served at the moment still have DTSTART and DTEND values that end in a Z, meaning that they're interpreted as being in UTC / GMT, so when I import things into my calendar they're all off by four hours. (I'm in Eastern Daylight time, which is currently four hours behind UTC.)

The default_tzid declaration on line 25 of app/lib/calendar_renderer.rb isn't reflected in the .ics output, which lacks any mention of a default timezone.

I stared at the code for app/lib/calendar_renderer.rb and https://github.com/rubyredrick/ri_cal for a while hoping I was going to be able to suggest a fix, but I've never written any Ruby and this is likely to require some trial-and-error fiddling. I wish I could help!

[johnjmikucki]

@skandragon - Looking at the times in the ICS output, they appear numerically correct for EDT but labelled with a 'Z' -- for Zulu/GMT/UTC. My guess is that the event creation pathway doesn't prompt the user for the timezone (and convert to GMT prior to storage), and defaults to GMT instead of the EDT that you might expect for Pennsic. These "GMT" timestamps are then interpreted by the user's calendaring software as GMT times, causing them to appear 5 hrs early.

Were it mine to do, I would take a two-pronged approach-- first, to modify the Create/Update code to normalize to GMT as described above. And second, to retroactively correct all the events currently in the DB; back it up, schedule a Thing outage for an hour, and run a one-shot DB migration to set the timezone to EDT on all the events currently in the DB.

[LisaLBeard]

Will this issue be fixed by Pennsic? I keep deleting my schedule and resubscribing hoping that this will have been corrected?

[Artimisia]

On Jul 15, 2017, at 10:07 PM, LisaLBeard notifications@github.com wrote:

Will this issue be fixed by Pennsic?

They hope so. They are working on it. If not it will be fixed at Pennsic when the Thing programmers actually have time that is not a day job to work on it.

I keep deleting my schedule and resubscribing hoping that this will have been corrected?

This has been suggested as a fix -

"I have managed to edit the iCal file to correct the problem, though I didn't know anything about the iCal parameters for timezone. It's possible it could cause some other problem for some users, but it works for me. Also, obviously it only helps if you don't need to subscribe for updates. From one of my own exported calendars, I copied the line X-WR-TIMEZONE:US/Eastern into the .ics file I had saved from Thing, using a text editor. (I inserted it after line 6, which begins "X-WR-RELCALID:" but I don't think it matters.)

In addition, I removed the letter 'Z' from the end of all start and end times. Possibly this difference is only necessary for older iCal versions. I used a find and replace on '00Z' to '00'. This seems to do the trick without causing any problems, but I didn't carefully check what other parameters are affected"

Hope this helps.

Gwynnyd

Baroness Gwynnyd Registrar, Pennsic University Pennsic War 46

universityregistrar@pennsicwar.org
or gwynnyd@gmail.com

---

Illud Latine dici non possum

[johnjmikucki]

Believe @skandragon fixed it (/worked around) with https://github.com/skandragon/thing/commit/c513224c358539bff15d2d290be086e32f7be553#diff-a62a269cc2c2a8492039072866677478

I exported the 'all' ICS just now and it appears to work correctly! Vivaunt!

[mcavalletto]

Agreed, it works! So excellent -- just in time! Many thanks!