Why doesn't RTM tell us that Google Calendar DOES NOT update RTM feeds?
michael.charvet says:
I've done a good amount of digging on this topic, and from the hundreds of posts on various forums, it's clear that Google Calendar does not update incoming feeds fast enough to be of any use -- this applies to RTM or any other application. Reports range from a few hours to never.
So why doesn't RTM just acknowledge this instead of lamely suggesting users contact Google? Sure we can all bitch at Google, but as a developer, it seems to me RTM should be on the phone with Google every day, and furthermore organizing large groups of people to submit thousands upon thousands of requests that Google fix the lack of manual or quick automatic updating of feeds.
As it is, RTM feeds in Google Calendar are totally and completely USELESS. It's disingenuous for RTM to say, "hey, check out this cool feature, upgrade to pro!" when in fact, they know very well that Google Calendar is not usable in any reasonable way. When will Google fix this huge oversight? Maybe never if you don't all apply pressure.
So why doesn't RTM just acknowledge this instead of lamely suggesting users contact Google? Sure we can all bitch at Google, but as a developer, it seems to me RTM should be on the phone with Google every day, and furthermore organizing large groups of people to submit thousands upon thousands of requests that Google fix the lack of manual or quick automatic updating of feeds.
As it is, RTM feeds in Google Calendar are totally and completely USELESS. It's disingenuous for RTM to say, "hey, check out this cool feature, upgrade to pro!" when in fact, they know very well that Google Calendar is not usable in any reasonable way. When will Google fix this huge oversight? Maybe never if you don't all apply pressure.
For the record, I use this every day and it works fine. I find the update is on the order of 1-3 hours, and that's plenty to have my agenda ready for the next day.
So it's not useless for all of us, and I think the forum is biased by (understandably) only hearing from those who are frustrated by some non-universal issue.
So it's not useless for all of us, and I think the forum is biased by (understandably) only hearing from those who are frustrated by some non-universal issue.
michael.charvet says:
I'd like to see a poll of users who are satisfied with this fuctionality versus those who are not.
I added some items to RTM yesterday and they still haven't shown up in Google Calendar. To me, that's a feature that simply doesn't work. And I've read many, many posts on different forums telling of similar experiences.
Again, as far as I know, this is not a shortcoming of RTM technology.
What irks me is that RTM doesn't disclose up front what's happening. Something like this: "Due to Google's current internal policies, be aware that Google Calendar may not update feeds from RTM in a timely fashion". Instead, RTM says "You can subscribe to your iCalendar feed so that Google Calendar can stay up-to-date with your Remember The Milk tasks". That's just not true.
I added some items to RTM yesterday and they still haven't shown up in Google Calendar. To me, that's a feature that simply doesn't work. And I've read many, many posts on different forums telling of similar experiences.
Again, as far as I know, this is not a shortcoming of RTM technology.
What irks me is that RTM doesn't disclose up front what's happening. Something like this: "Due to Google's current internal policies, be aware that Google Calendar may not update feeds from RTM in a timely fashion". Instead, RTM says "You can subscribe to your iCalendar feed so that Google Calendar can stay up-to-date with your Remember The Milk tasks". That's just not true.
michael.charvet says:
Everyone -- check out this demo of Spanning Sync -- a sync application for Mac. It auto-syncs Apple's iCal to Google Calendar every 10 minutes. So it appears that it's possible to update Google Calendar from an outside application. If that's the case, then the responsibility to implement a solution that auto-synces falls to RTM, not Google.
http://spanningsync.com/screencasts/intro/
http://spanningsync.com/screencasts/intro/
wernst says:
First, let's be clear. I am a user that has problems with Google Calendar and RTM. Sometimes. It's frustrating. I have 3 smartlists that Google Calendar is set to monitor via iCal Events. Some weeks, all 3 work fine, with GCal getting updates within 3 or 4 hours. Some weeks, NONE OF THEM GET UPDATES. This week, two of my three feeds are getting updates and one is not.
I'm not entirely convinced this isn't RTM's "fault." I am also not entirely convinced this is Google's fault. I suspect Google suggested a range of ways to perform this task, RTM employed a method that is strictly speaking within Google's range, but in fact is close to one of the edges, and as a result, it works unreliably.
Here's my weird evidence.
There's another service out there called Airset (www.airset.com) and it is free, and tries to offer basic groupware. One of the things it has is a Calendar, and it can BOTH IMPORT AND EXPORT iCAL FEEDS.
So what I can do is tell Airset to grab my 3 RTM iCal feeds and display it in its calendar. THESE ARE THE SAME FEEDS CGal sometimes balks at, so clearly they are "technically correct."
Then I can tell Airset to export my three RTM iCal Feeds of its own. Airset then assigns three new iCal Feed URLs. Basically, Airset is just forwarding my RTM iCal feeds from RTM and making them available as a new, VASTLY SIMPLIFIED URL being hosted on a server that isn't RTM's.
And here's the kicker: CGal has NO PROBLEMS WHATSOEVER staying up to date with these feeds from Airset. They've been reliably updated within 3 hours every day. Every feed.
Since I have CGal monitoring 6 feeds, three of which should be identical to each other, I can see in real-time when Gcal is balking at RTMs' feeds and happily accepting Airsets'.
What's the difference? Well, there are two:
The first difference are the servers: the one Google sometimes balks at is run by the RTM team. The other is run by the Airset team. Maybe there's an RTM server problem that is subtle and irregular. That's totally a real possibility. I know. I run servers for web services as one of my professional tasks. But maybe it's not the problem. Only the RTM people can say for sure, but they should really REALLY be checking for it.
The second difference are the URLs. They are very different.
RTM's feed URLs look like this (a few letters are changed to make this an example):
webcal://www.rememberthemilk.com/icalendar/wernst/3094925/events/?tok=eJwNy0sKQjEMBdAVPUja5rec3CYFQRyo4PZ9kzM7raAF7PREdJJEcUsM2FQtl41234GwpjrZNtlFy2u2nUV9-fr9*nyv5*NmUqwYcjGHsyanHRYOk9MaZrGzpzS41rFTgtHpohvmByvvrQIzqj9meioF
Airset's look like this:
http://www.airset.com/services/iCal/private/mMFhVHXWPwDSvCUBnG1234JQhFXJbFoGAdjEDMLbVTwlGIzM/Personal.ics
I bet RTM's syntax is perfectly legal from a technical standpoint, but clearly, Airset's is cleaner URL is getting results where GCal is concerned. Maybe GCal isn't parsing the long URL correctly all the time. Maybe long URLs get lower update priorities. How should I know? How should the RTM team know? Beat's me, but this is something that should be EASY for the RTM team to check and test.
If I were a developer of RTM, I would start offering MUCH smaller URLs for the iCal Event feed. I would make sure they begin with http://. I would make sure they end with a real .ICS filename instead of a bunch of gibberish. And then I would ask my users if there is any improvement.
I would run a second server to host iCal feeds as a test. Just do it internally. Then set up dozens of regularly updated test feeds and see which ones and from where GCal is able to work with reliably and which ones it can't.
Come on, guys, I did all the legwork for you! All you need to do is set up some test accounts and test feeds, see if it works, and then report back to us.
I'm just one guy (true, I was a professional QA engineer for Toshiba, Symantec, and other major hardware and software companies in my earlier years) testing just half a dozen feeds, yet I'm seeing a pattern. Surely the RTM developers, working with lots of test feeds and being able to monitor their server logs, should be able to spot a similar pattern and track down its causes better than I can. All it takes is effort. And that sometimes seems like the problem.
If you sense exasperation on my part and on other user's parts, it's because it seems from our end that no effort is being spent by the RTM staff to REALLY INVESTIGATE THIS PROBLEM, other than to say "Hey it's Google's problem, and all our stuff is fine." I'm sure that's not the case, but that's how it sometimes looks.
GCal is the 900 pound gorilla in the web calendar market. RTM is the smaller, complimentary service that is trying to work with it. It seems to me that this means RTM needs to work harder to be compatible with the 900 pound gorilla than vice versa. To put it another way, if Internet Explorer were suddenly displaying RTM incorrectly, even if your HTML and Javascript were all technically correct, you wouldn't be telling users "Hey, our code is all correct, since it looks fine in Firefox. Please contact Microsoft and ask them to fix IE so RTM works with it." You would look into the problem, shake your head and mutter about Microsoft's stupidity, and then change your code so it works in IE.
It's the same thing with GCal.
Awaiting with baited breath for a response...
(and sorry for the long post. This rant/troubleshooting session has been on my todo list for a few weeks now)
-Warr
I'm not entirely convinced this isn't RTM's "fault." I am also not entirely convinced this is Google's fault. I suspect Google suggested a range of ways to perform this task, RTM employed a method that is strictly speaking within Google's range, but in fact is close to one of the edges, and as a result, it works unreliably.
Here's my weird evidence.
There's another service out there called Airset (www.airset.com) and it is free, and tries to offer basic groupware. One of the things it has is a Calendar, and it can BOTH IMPORT AND EXPORT iCAL FEEDS.
So what I can do is tell Airset to grab my 3 RTM iCal feeds and display it in its calendar. THESE ARE THE SAME FEEDS CGal sometimes balks at, so clearly they are "technically correct."
Then I can tell Airset to export my three RTM iCal Feeds of its own. Airset then assigns three new iCal Feed URLs. Basically, Airset is just forwarding my RTM iCal feeds from RTM and making them available as a new, VASTLY SIMPLIFIED URL being hosted on a server that isn't RTM's.
And here's the kicker: CGal has NO PROBLEMS WHATSOEVER staying up to date with these feeds from Airset. They've been reliably updated within 3 hours every day. Every feed.
Since I have CGal monitoring 6 feeds, three of which should be identical to each other, I can see in real-time when Gcal is balking at RTMs' feeds and happily accepting Airsets'.
What's the difference? Well, there are two:
The first difference are the servers: the one Google sometimes balks at is run by the RTM team. The other is run by the Airset team. Maybe there's an RTM server problem that is subtle and irregular. That's totally a real possibility. I know. I run servers for web services as one of my professional tasks. But maybe it's not the problem. Only the RTM people can say for sure, but they should really REALLY be checking for it.
The second difference are the URLs. They are very different.
RTM's feed URLs look like this (a few letters are changed to make this an example):
webcal://www.rememberthemilk.com/icalendar/wernst/3094925/events/?tok=eJwNy0sKQjEMBdAVPUja5rec3CYFQRyo4PZ9kzM7raAF7PREdJJEcUsM2FQtl41234GwpjrZNtlFy2u2nUV9-fr9*nyv5*NmUqwYcjGHsyanHRYOk9MaZrGzpzS41rFTgtHpohvmByvvrQIzqj9meioF
Airset's look like this:
http://www.airset.com/services/iCal/private/mMFhVHXWPwDSvCUBnG1234JQhFXJbFoGAdjEDMLbVTwlGIzM/Personal.ics
I bet RTM's syntax is perfectly legal from a technical standpoint, but clearly, Airset's is cleaner URL is getting results where GCal is concerned. Maybe GCal isn't parsing the long URL correctly all the time. Maybe long URLs get lower update priorities. How should I know? How should the RTM team know? Beat's me, but this is something that should be EASY for the RTM team to check and test.
If I were a developer of RTM, I would start offering MUCH smaller URLs for the iCal Event feed. I would make sure they begin with http://. I would make sure they end with a real .ICS filename instead of a bunch of gibberish. And then I would ask my users if there is any improvement.
I would run a second server to host iCal feeds as a test. Just do it internally. Then set up dozens of regularly updated test feeds and see which ones and from where GCal is able to work with reliably and which ones it can't.
Come on, guys, I did all the legwork for you! All you need to do is set up some test accounts and test feeds, see if it works, and then report back to us.
I'm just one guy (true, I was a professional QA engineer for Toshiba, Symantec, and other major hardware and software companies in my earlier years) testing just half a dozen feeds, yet I'm seeing a pattern. Surely the RTM developers, working with lots of test feeds and being able to monitor their server logs, should be able to spot a similar pattern and track down its causes better than I can. All it takes is effort. And that sometimes seems like the problem.
If you sense exasperation on my part and on other user's parts, it's because it seems from our end that no effort is being spent by the RTM staff to REALLY INVESTIGATE THIS PROBLEM, other than to say "Hey it's Google's problem, and all our stuff is fine." I'm sure that's not the case, but that's how it sometimes looks.
GCal is the 900 pound gorilla in the web calendar market. RTM is the smaller, complimentary service that is trying to work with it. It seems to me that this means RTM needs to work harder to be compatible with the 900 pound gorilla than vice versa. To put it another way, if Internet Explorer were suddenly displaying RTM incorrectly, even if your HTML and Javascript were all technically correct, you wouldn't be telling users "Hey, our code is all correct, since it looks fine in Firefox. Please contact Microsoft and ask them to fix IE so RTM works with it." You would look into the problem, shake your head and mutter about Microsoft's stupidity, and then change your code so it works in IE.
It's the same thing with GCal.
Awaiting with baited breath for a response...
(and sorry for the long post. This rant/troubleshooting session has been on my todo list for a few weeks now)
-Warr
wernst says:
Oh, and I forgot to mention one more thing. A potential third problem is the format of the base ICS data that both Airset and RTM are feeding to Google. RTM's ICS feed could be different enough that it causes Google Calendar problems.
I can give you a perfect example.
Here's the output of two feeds. They are both for three identical test events. The RTM one comes directly from RTM. The Airset feed comes from getting the initial feed from RTM, and then repubishing it Airset's own feed. Again, these are for the same three test events:
RTM:
--------------snip--------------
BEGIN:VCALENDAR
PRODID:-//Remember The Milk//rtm.Service.iCalendar.Export 3.0//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:PUBLISH
X-WR-CALNAME:TestRTMEvents
LAST-MODIFIED:20081104T190336Z
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:20070311T020000
RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:20071104T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:STANDARD
TZOFFSETFROM:-0752
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:18831118T120702
RDATE;VALUE=DATE-TIME:18831118T120702
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:19180331T020000
RDATE;VALUE=DATE-TIME:19180331T020000
RDATE;VALUE=DATE-TIME:19190330T020000
RDATE;VALUE=DATE-TIME:19480314T020000
RDATE;VALUE=DATE-TIME:19500430T020000
RDATE;VALUE=DATE-TIME:19510429T020000
RDATE;VALUE=DATE-TIME:19520427T020000
RDATE;VALUE=DATE-TIME:19530426T020000
RDATE;VALUE=DATE-TIME:19540425T020000
RDATE;VALUE=DATE-TIME:19550424T020000
RDATE;VALUE=DATE-TIME:19560429T020000
RDATE;VALUE=DATE-TIME:19570428T020000
RDATE;VALUE=DATE-TIME:19580427T020000
RDATE;VALUE=DATE-TIME:19590426T020000
RDATE;VALUE=DATE-TIME:19600424T020000
RDATE;VALUE=DATE-TIME:19610430T020000
RDATE;VALUE=DATE-TIME:19620429T020000
RDATE;VALUE=DATE-TIME:19630428T020000
RDATE;VALUE=DATE-TIME:19640426T020000
RDATE;VALUE=DATE-TIME:19650425T020000
RDATE;VALUE=DATE-TIME:19660424T020000
RDATE;VALUE=DATE-TIME:19670430T020000
RDATE;VALUE=DATE-TIME:19680428T020000
RDATE;VALUE=DATE-TIME:19690427T020000
RDATE;VALUE=DATE-TIME:19700426T020000
RDATE;VALUE=DATE-TIME:19710425T020000
RDATE;VALUE=DATE-TIME:19720430T020000
RDATE;VALUE=DATE-TIME:19730429T020000
RDATE;VALUE=DATE-TIME:19740106T020000
RDATE;VALUE=DATE-TIME:19750223T020000
RDATE;VALUE=DATE-TIME:19760425T020000
RDATE;VALUE=DATE-TIME:19770424T020000
RDATE;VALUE=DATE-TIME:19780430T020000
RDATE;VALUE=DATE-TIME:19790429T020000
RDATE;VALUE=DATE-TIME:19800427T020000
RDATE;VALUE=DATE-TIME:19810426T020000
RDATE;VALUE=DATE-TIME:19820425T020000
RDATE;VALUE=DATE-TIME:19830424T020000
RDATE;VALUE=DATE-TIME:19840429T020000
RDATE;VALUE=DATE-TIME:19850428T020000
RDATE;VALUE=DATE-TIME:19860427T020000
RDATE;VALUE=DATE-TIME:19870405T020000
RDATE;VALUE=DATE-TIME:19880403T020000
RDATE;VALUE=DATE-TIME:19890402T020000
RDATE;VALUE=DATE-TIME:19900401T020000
RDATE;VALUE=DATE-TIME:19910407T020000
RDATE;VALUE=DATE-TIME:19920405T020000
RDATE;VALUE=DATE-TIME:19930404T020000
RDATE;VALUE=DATE-TIME:19940403T020000
RDATE;VALUE=DATE-TIME:19950402T020000
RDATE;VALUE=DATE-TIME:19960407T020000
RDATE;VALUE=DATE-TIME:19970406T020000
RDATE;VALUE=DATE-TIME:19980405T020000
RDATE;VALUE=DATE-TIME:19990404T020000
RDATE;VALUE=DATE-TIME:20000402T020000
RDATE;VALUE=DATE-TIME:20010401T020000
RDATE;VALUE=DATE-TIME:20020407T020000
RDATE;VALUE=DATE-TIME:20030406T020000
RDATE;VALUE=DATE-TIME:20040404T020000
RDATE;VALUE=DATE-TIME:20050403T020000
RDATE;VALUE=DATE-TIME:20060402T020000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19181027T020000
RDATE;VALUE=DATE-TIME:19181027T020000
RDATE;VALUE=DATE-TIME:19191026T020000
RDATE;VALUE=DATE-TIME:19450930T020000
RDATE;VALUE=DATE-TIME:19490101T020000
RDATE;VALUE=DATE-TIME:19500924T020000
RDATE;VALUE=DATE-TIME:19510930T020000
RDATE;VALUE=DATE-TIME:19520928T020000
RDATE;VALUE=DATE-TIME:19530927T020000
RDATE;VALUE=DATE-TIME:19540926T020000
RDATE;VALUE=DATE-TIME:19550925T020000
RDATE;VALUE=DATE-TIME:19560930T020000
RDATE;VALUE=DATE-TIME:19570929T020000
RDATE;VALUE=DATE-TIME:19580928T020000
RDATE;VALUE=DATE-TIME:19590927T020000
RDATE;VALUE=DATE-TIME:19600925T020000
RDATE;VALUE=DATE-TIME:19610924T020000
RDATE;VALUE=DATE-TIME:19621028T020000
RDATE;VALUE=DATE-TIME:19631027T020000
RDATE;VALUE=DATE-TIME:19641025T020000
RDATE;VALUE=DATE-TIME:19651031T020000
RDATE;VALUE=DATE-TIME:19661030T020000
RDATE;VALUE=DATE-TIME:19671029T020000
RDATE;VALUE=DATE-TIME:19681027T020000
RDATE;VALUE=DATE-TIME:19691026T020000
RDATE;VALUE=DATE-TIME:19701025T020000
RDATE;VALUE=DATE-TIME:19711031T020000
RDATE;VALUE=DATE-TIME:19721029T020000
RDATE;VALUE=DATE-TIME:19731028T020000
RDATE;VALUE=DATE-TIME:19741027T020000
RDATE;VALUE=DATE-TIME:19751026T020000
RDATE;VALUE=DATE-TIME:19761031T020000
RDATE;VALUE=DATE-TIME:19771030T020000
RDATE;VALUE=DATE-TIME:19781029T020000
RDATE;VALUE=DATE-TIME:19791028T020000
RDATE;VALUE=DATE-TIME:19801026T020000
RDATE;VALUE=DATE-TIME:19811025T020000
RDATE;VALUE=DATE-TIME:19821031T020000
RDATE;VALUE=DATE-TIME:19831030T020000
RDATE;VALUE=DATE-TIME:19841028T020000
RDATE;VALUE=DATE-TIME:19851027T020000
RDATE;VALUE=DATE-TIME:19861026T020000
RDATE;VALUE=DATE-TIME:19871025T020000
RDATE;VALUE=DATE-TIME:19881030T020000
RDATE;VALUE=DATE-TIME:19891029T020000
RDATE;VALUE=DATE-TIME:19901028T020000
RDATE;VALUE=DATE-TIME:19911027T020000
RDATE;VALUE=DATE-TIME:19921025T020000
RDATE;VALUE=DATE-TIME:19931031T020000
RDATE;VALUE=DATE-TIME:19941030T020000
RDATE;VALUE=DATE-TIME:19951029T020000
RDATE;VALUE=DATE-TIME:19961027T020000
RDATE;VALUE=DATE-TIME:19971026T020000
RDATE;VALUE=DATE-TIME:19981025T020000
RDATE;VALUE=DATE-TIME:19991031T020000
RDATE;VALUE=DATE-TIME:20001029T020000
RDATE;VALUE=DATE-TIME:20011028T020000
RDATE;VALUE=DATE-TIME:20021027T020000
RDATE;VALUE=DATE-TIME:20031026T020000
RDATE;VALUE=DATE-TIME:20041031T020000
RDATE;VALUE=DATE-TIME:20051030T020000
RDATE;VALUE=DATE-TIME:20061029T020000
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PWT
DTSTART:19420209T020000
RDATE;VALUE=DATE-TIME:19420209T020000
END:DAYLIGHT
BEGIN:DAYLIGHT
TZOFFSETFROM:-0700
TZOFFSETTO:-0700
TZNAME:PPT
DTSTART:19450814T160000
RDATE;VALUE=DATE-TIME:19450814T160000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0800
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19460101T000000
RDATE;VALUE=DATE-TIME:19460101T000000
RDATE;VALUE=DATE-TIME:19670101T000000
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20081103T220407Z
LAST-MODIFIED:20081104T190336Z
DTSTAMP:20081104T190336Z
SUMMARY:test event 2
UID:FFFFFFFF-FFFF-FFFF-FFFF-FFFF36082025
SEQUENCE:75568
TRANSP:OPAQUE
DESCRIPTION:Tags: .testevent\nLocation: none\n\n
DTSTART;VALUE=DATE:20081123
DTEND;VALUE=DATE:20081124
PRIORITY:9
STATUS:CONFIRMED
END:VEVENT
BEGIN:VEVENT
CREATED:20081103T220403Z
LAST-MODIFIED:20081104T190336Z
DTSTAMP:20081104T190336Z
SUMMARY:test event 1
UID:FFFFFFFF-FFFF-FFFF-FFFF-FFFF36082018
SEQUENCE:75572
TRANSP:OPAQUE
DESCRIPTION:Tags: .testevent\nLocation: none\n\n
DTSTART;VALUE=DATE:20081122
DTEND;VALUE=DATE:20081123
STATUS:CONFIRMED
END:VEVENT
BEGIN:VEVENT
CREATED:20081103T221816Z
LAST-MODIFIED:20081104T190336Z
DTSTAMP:20081104T190336Z
SUMMARY:test event 3 added 11/3/08 2:15pm
UID:FFFFFFFF-FFFF-FFFF-FFFF-FFFF36083760
SEQUENCE:74719
TRANSP:OPAQUE
DESCRIPTION:Tags: .testevent\nLocation: none\n\n
DTSTART;VALUE=DATE:20081124
DTEND;VALUE=DATE:20081125
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
--------------snip--------------
Airset:
--------------snip--------------
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Airena\, Inc//AirSet 1.6G//EN
X-WR-TIMEZONE:America/Los_Angeles
METHOD:PUBLISH
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
DTSTART:19870308T020000
RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:19871101T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;VALUE=DATE:20081122
DTEND;VALUE=DATE:20081123
SUMMARY:test event 1
DESCRIPTION:Tags: .testevent\nLocation: none
X-AIRSET-GROUP:Other
UID:ysEAPONcTFnFpzIWTTjxJKTB@airset.com
DTSTAMP:20081103T220500Z
END:VEVENT
BEGIN:VEVENT
DTSTART;VALUE=DATE:20081123
DTEND;VALUE=DATE:20081124
SUMMARY:test event 2
DESCRIPTION:Tags: .testevent\nLocation: none
X-AIRSET-GROUP:Other
UID:ysEAPONcTFnFnXVDuKIkWzJM@airset.com
DTSTAMP:20081103T220600Z
END:VEVENT
BEGIN:VEVENT
DTSTART;VALUE=DATE:20081124
DTEND;VALUE=DATE:20081125
SUMMARY:test event 3 added 11/3/08 2:15pm
DESCRIPTION:Tags: .testevent\nLocation: none
X-AIRSET-GROUP:Other
UID:ysEAPONcTFnFucNhMOIjDAiW@airset.com
DTSTAMP:20081103T221800Z
END:VEVENT
END:VCALENDAR
--------------snip--------------
See? The Airset ICS file has a lot less extra lines. What are those extra lines? I have no idea. But I'm not an RTM developer. An RTM developer should have some idea.
Again, this is an example of something that RTM should be checking on instead of a user like me, IMHO.
Food for thought. Eagerly awaiting some reply.
-Warr
I can give you a perfect example.
Here's the output of two feeds. They are both for three identical test events. The RTM one comes directly from RTM. The Airset feed comes from getting the initial feed from RTM, and then repubishing it Airset's own feed. Again, these are for the same three test events:
RTM:
--------------snip--------------
BEGIN:VCALENDAR
PRODID:-//Remember The Milk//rtm.Service.iCalendar.Export 3.0//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:PUBLISH
X-WR-CALNAME:TestRTMEvents
LAST-MODIFIED:20081104T190336Z
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:20070311T020000
RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:20071104T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:STANDARD
TZOFFSETFROM:-0752
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:18831118T120702
RDATE;VALUE=DATE-TIME:18831118T120702
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:19180331T020000
RDATE;VALUE=DATE-TIME:19180331T020000
RDATE;VALUE=DATE-TIME:19190330T020000
RDATE;VALUE=DATE-TIME:19480314T020000
RDATE;VALUE=DATE-TIME:19500430T020000
RDATE;VALUE=DATE-TIME:19510429T020000
RDATE;VALUE=DATE-TIME:19520427T020000
RDATE;VALUE=DATE-TIME:19530426T020000
RDATE;VALUE=DATE-TIME:19540425T020000
RDATE;VALUE=DATE-TIME:19550424T020000
RDATE;VALUE=DATE-TIME:19560429T020000
RDATE;VALUE=DATE-TIME:19570428T020000
RDATE;VALUE=DATE-TIME:19580427T020000
RDATE;VALUE=DATE-TIME:19590426T020000
RDATE;VALUE=DATE-TIME:19600424T020000
RDATE;VALUE=DATE-TIME:19610430T020000
RDATE;VALUE=DATE-TIME:19620429T020000
RDATE;VALUE=DATE-TIME:19630428T020000
RDATE;VALUE=DATE-TIME:19640426T020000
RDATE;VALUE=DATE-TIME:19650425T020000
RDATE;VALUE=DATE-TIME:19660424T020000
RDATE;VALUE=DATE-TIME:19670430T020000
RDATE;VALUE=DATE-TIME:19680428T020000
RDATE;VALUE=DATE-TIME:19690427T020000
RDATE;VALUE=DATE-TIME:19700426T020000
RDATE;VALUE=DATE-TIME:19710425T020000
RDATE;VALUE=DATE-TIME:19720430T020000
RDATE;VALUE=DATE-TIME:19730429T020000
RDATE;VALUE=DATE-TIME:19740106T020000
RDATE;VALUE=DATE-TIME:19750223T020000
RDATE;VALUE=DATE-TIME:19760425T020000
RDATE;VALUE=DATE-TIME:19770424T020000
RDATE;VALUE=DATE-TIME:19780430T020000
RDATE;VALUE=DATE-TIME:19790429T020000
RDATE;VALUE=DATE-TIME:19800427T020000
RDATE;VALUE=DATE-TIME:19810426T020000
RDATE;VALUE=DATE-TIME:19820425T020000
RDATE;VALUE=DATE-TIME:19830424T020000
RDATE;VALUE=DATE-TIME:19840429T020000
RDATE;VALUE=DATE-TIME:19850428T020000
RDATE;VALUE=DATE-TIME:19860427T020000
RDATE;VALUE=DATE-TIME:19870405T020000
RDATE;VALUE=DATE-TIME:19880403T020000
RDATE;VALUE=DATE-TIME:19890402T020000
RDATE;VALUE=DATE-TIME:19900401T020000
RDATE;VALUE=DATE-TIME:19910407T020000
RDATE;VALUE=DATE-TIME:19920405T020000
RDATE;VALUE=DATE-TIME:19930404T020000
RDATE;VALUE=DATE-TIME:19940403T020000
RDATE;VALUE=DATE-TIME:19950402T020000
RDATE;VALUE=DATE-TIME:19960407T020000
RDATE;VALUE=DATE-TIME:19970406T020000
RDATE;VALUE=DATE-TIME:19980405T020000
RDATE;VALUE=DATE-TIME:19990404T020000
RDATE;VALUE=DATE-TIME:20000402T020000
RDATE;VALUE=DATE-TIME:20010401T020000
RDATE;VALUE=DATE-TIME:20020407T020000
RDATE;VALUE=DATE-TIME:20030406T020000
RDATE;VALUE=DATE-TIME:20040404T020000
RDATE;VALUE=DATE-TIME:20050403T020000
RDATE;VALUE=DATE-TIME:20060402T020000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19181027T020000
RDATE;VALUE=DATE-TIME:19181027T020000
RDATE;VALUE=DATE-TIME:19191026T020000
RDATE;VALUE=DATE-TIME:19450930T020000
RDATE;VALUE=DATE-TIME:19490101T020000
RDATE;VALUE=DATE-TIME:19500924T020000
RDATE;VALUE=DATE-TIME:19510930T020000
RDATE;VALUE=DATE-TIME:19520928T020000
RDATE;VALUE=DATE-TIME:19530927T020000
RDATE;VALUE=DATE-TIME:19540926T020000
RDATE;VALUE=DATE-TIME:19550925T020000
RDATE;VALUE=DATE-TIME:19560930T020000
RDATE;VALUE=DATE-TIME:19570929T020000
RDATE;VALUE=DATE-TIME:19580928T020000
RDATE;VALUE=DATE-TIME:19590927T020000
RDATE;VALUE=DATE-TIME:19600925T020000
RDATE;VALUE=DATE-TIME:19610924T020000
RDATE;VALUE=DATE-TIME:19621028T020000
RDATE;VALUE=DATE-TIME:19631027T020000
RDATE;VALUE=DATE-TIME:19641025T020000
RDATE;VALUE=DATE-TIME:19651031T020000
RDATE;VALUE=DATE-TIME:19661030T020000
RDATE;VALUE=DATE-TIME:19671029T020000
RDATE;VALUE=DATE-TIME:19681027T020000
RDATE;VALUE=DATE-TIME:19691026T020000
RDATE;VALUE=DATE-TIME:19701025T020000
RDATE;VALUE=DATE-TIME:19711031T020000
RDATE;VALUE=DATE-TIME:19721029T020000
RDATE;VALUE=DATE-TIME:19731028T020000
RDATE;VALUE=DATE-TIME:19741027T020000
RDATE;VALUE=DATE-TIME:19751026T020000
RDATE;VALUE=DATE-TIME:19761031T020000
RDATE;VALUE=DATE-TIME:19771030T020000
RDATE;VALUE=DATE-TIME:19781029T020000
RDATE;VALUE=DATE-TIME:19791028T020000
RDATE;VALUE=DATE-TIME:19801026T020000
RDATE;VALUE=DATE-TIME:19811025T020000
RDATE;VALUE=DATE-TIME:19821031T020000
RDATE;VALUE=DATE-TIME:19831030T020000
RDATE;VALUE=DATE-TIME:19841028T020000
RDATE;VALUE=DATE-TIME:19851027T020000
RDATE;VALUE=DATE-TIME:19861026T020000
RDATE;VALUE=DATE-TIME:19871025T020000
RDATE;VALUE=DATE-TIME:19881030T020000
RDATE;VALUE=DATE-TIME:19891029T020000
RDATE;VALUE=DATE-TIME:19901028T020000
RDATE;VALUE=DATE-TIME:19911027T020000
RDATE;VALUE=DATE-TIME:19921025T020000
RDATE;VALUE=DATE-TIME:19931031T020000
RDATE;VALUE=DATE-TIME:19941030T020000
RDATE;VALUE=DATE-TIME:19951029T020000
RDATE;VALUE=DATE-TIME:19961027T020000
RDATE;VALUE=DATE-TIME:19971026T020000
RDATE;VALUE=DATE-TIME:19981025T020000
RDATE;VALUE=DATE-TIME:19991031T020000
RDATE;VALUE=DATE-TIME:20001029T020000
RDATE;VALUE=DATE-TIME:20011028T020000
RDATE;VALUE=DATE-TIME:20021027T020000
RDATE;VALUE=DATE-TIME:20031026T020000
RDATE;VALUE=DATE-TIME:20041031T020000
RDATE;VALUE=DATE-TIME:20051030T020000
RDATE;VALUE=DATE-TIME:20061029T020000
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PWT
DTSTART:19420209T020000
RDATE;VALUE=DATE-TIME:19420209T020000
END:DAYLIGHT
BEGIN:DAYLIGHT
TZOFFSETFROM:-0700
TZOFFSETTO:-0700
TZNAME:PPT
DTSTART:19450814T160000
RDATE;VALUE=DATE-TIME:19450814T160000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0800
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19460101T000000
RDATE;VALUE=DATE-TIME:19460101T000000
RDATE;VALUE=DATE-TIME:19670101T000000
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20081103T220407Z
LAST-MODIFIED:20081104T190336Z
DTSTAMP:20081104T190336Z
SUMMARY:test event 2
UID:FFFFFFFF-FFFF-FFFF-FFFF-FFFF36082025
SEQUENCE:75568
TRANSP:OPAQUE
DESCRIPTION:Tags: .testevent\nLocation: none\n\n
DTSTART;VALUE=DATE:20081123
DTEND;VALUE=DATE:20081124
PRIORITY:9
STATUS:CONFIRMED
END:VEVENT
BEGIN:VEVENT
CREATED:20081103T220403Z
LAST-MODIFIED:20081104T190336Z
DTSTAMP:20081104T190336Z
SUMMARY:test event 1
UID:FFFFFFFF-FFFF-FFFF-FFFF-FFFF36082018
SEQUENCE:75572
TRANSP:OPAQUE
DESCRIPTION:Tags: .testevent\nLocation: none\n\n
DTSTART;VALUE=DATE:20081122
DTEND;VALUE=DATE:20081123
STATUS:CONFIRMED
END:VEVENT
BEGIN:VEVENT
CREATED:20081103T221816Z
LAST-MODIFIED:20081104T190336Z
DTSTAMP:20081104T190336Z
SUMMARY:test event 3 added 11/3/08 2:15pm
UID:FFFFFFFF-FFFF-FFFF-FFFF-FFFF36083760
SEQUENCE:74719
TRANSP:OPAQUE
DESCRIPTION:Tags: .testevent\nLocation: none\n\n
DTSTART;VALUE=DATE:20081124
DTEND;VALUE=DATE:20081125
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
--------------snip--------------
Airset:
--------------snip--------------
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Airena\, Inc//AirSet 1.6G//EN
X-WR-TIMEZONE:America/Los_Angeles
METHOD:PUBLISH
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
DTSTART:19870308T020000
RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:19871101T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;VALUE=DATE:20081122
DTEND;VALUE=DATE:20081123
SUMMARY:test event 1
DESCRIPTION:Tags: .testevent\nLocation: none
X-AIRSET-GROUP:Other
UID:ysEAPONcTFnFpzIWTTjxJKTB@airset.com
DTSTAMP:20081103T220500Z
END:VEVENT
BEGIN:VEVENT
DTSTART;VALUE=DATE:20081123
DTEND;VALUE=DATE:20081124
SUMMARY:test event 2
DESCRIPTION:Tags: .testevent\nLocation: none
X-AIRSET-GROUP:Other
UID:ysEAPONcTFnFnXVDuKIkWzJM@airset.com
DTSTAMP:20081103T220600Z
END:VEVENT
BEGIN:VEVENT
DTSTART;VALUE=DATE:20081124
DTEND;VALUE=DATE:20081125
SUMMARY:test event 3 added 11/3/08 2:15pm
DESCRIPTION:Tags: .testevent\nLocation: none
X-AIRSET-GROUP:Other
UID:ysEAPONcTFnFucNhMOIjDAiW@airset.com
DTSTAMP:20081103T221800Z
END:VEVENT
END:VCALENDAR
--------------snip--------------
See? The Airset ICS file has a lot less extra lines. What are those extra lines? I have no idea. But I'm not an RTM developer. An RTM developer should have some idea.
Again, this is an example of something that RTM should be checking on instead of a user like me, IMHO.
Food for thought. Eagerly awaiting some reply.
-Warr
(closed account) says:
Just to note that I've duplicated the experiment by Warr by using my Airset account (forgot that I had one until today ;) and am seeing the exact same behavior. iCal feeds from airset are working fine in google calendar (though at their glacial update pace). The airset calendar is actually pretty decent and, *gasp*, allows you to manually refresh your feeds (cmon google....if they can do it you can to).
So...not sure what is going on here but there is something odd going on between google and RTM.
So...not sure what is going on here but there is something odd going on between google and RTM.
emily (Remember The Milk) says:
wernst, we've done a lot of investigation into this issue -- Google Calendar is successfully fetching hundreds of thousands of iCalendar feed updates from our servers each day, so it seems to be working for many RTM users.
You mentioned that two of your feeds were updating properly but one wasn't -- we really need to get that affected feed URL from you. Please submit an issue report and let us know the affected URL. We cannot investigate your issue further without this URL.
(For anyone else who has an iCalendar subscription taking more than 24 hours to update in Google Calendar, first double check to make sure your subscription is for the correct URL, then submit an issue report and let us know the URL.)
Once we have the affected iCalendar URL from you, we'll be able to check our servers to see if:
1) Google Calendar isn't fetching the URL at the expected times (in which case you'd need to ask the Google Calendar team to investigate on their end).
2) Google Calendar is fetching the URL at the expected times, but the updates aren't reflected in Google Calendar (in which case you'd need to ask the Google Calendar team to investigate on their end).
3) There are any errors on our servers which indicate why there would be any problems fetching this particular URL (we've already checked extensively for errors across all iCalendar feeds and with our own test feeds, but this would tell us if there is something specific happening to that URL).
Thank you.
You mentioned that two of your feeds were updating properly but one wasn't -- we really need to get that affected feed URL from you. Please submit an issue report and let us know the affected URL. We cannot investigate your issue further without this URL.
(For anyone else who has an iCalendar subscription taking more than 24 hours to update in Google Calendar, first double check to make sure your subscription is for the correct URL, then submit an issue report and let us know the URL.)
Once we have the affected iCalendar URL from you, we'll be able to check our servers to see if:
1) Google Calendar isn't fetching the URL at the expected times (in which case you'd need to ask the Google Calendar team to investigate on their end).
2) Google Calendar is fetching the URL at the expected times, but the updates aren't reflected in Google Calendar (in which case you'd need to ask the Google Calendar team to investigate on their end).
3) There are any errors on our servers which indicate why there would be any problems fetching this particular URL (we've already checked extensively for errors across all iCalendar feeds and with our own test feeds, but this would tell us if there is something specific happening to that URL).
Thank you.
wernst says:
Emily,
Thanks very much for a prompt reply. I have, as requested, submitted an issue report with the URLs of the RTM feeds and the URLs of the corresponding Airset fees.
Regarding the successful fetching of hundreds of thousands of iCal feeds a day: I'm very glad to hear that and it is very impressive.
But let's not discount the possibility that there is something within the ICS feed RTM might be successfully supplying that is causing CGal to balk.
Thanks for the help, and I eagerly anticipate an analysis.
-Warr
Thanks very much for a prompt reply. I have, as requested, submitted an issue report with the URLs of the RTM feeds and the URLs of the corresponding Airset fees.
Regarding the successful fetching of hundreds of thousands of iCal feeds a day: I'm very glad to hear that and it is very impressive.
But let's not discount the possibility that there is something within the ICS feed RTM might be successfully supplying that is causing CGal to balk.
Thanks for the help, and I eagerly anticipate an analysis.
-Warr
emily (Remember The Milk) says:
Hi Warr,
Thanks for providing the iCalendar URLs privately.
We've checked our servers -- in the last 24hrs, Google Calendar has successfully fetched each of these URLs multiple times (the interval between fetches was between 4 and 8 hours; I've provided exact fetch times via email).
We've also checked to make sure that nothing was cached on our end (i.e. to make sure that when the fetch took place, it always got the latest version of your tasks). All files comply with the iCalendar specification (RFC 2445) for calendar data exchange; there's nothing to suggest why Google Calendar would potentially not update to reflect the latest feed update.
Given that the URLs are being fetched successfully by Google Calendar every 4 to 8 hours, unfortunately the only folks who can tell why your Google Calendar account isn't reflecting those updates are the Google Calendar team.
As I mentioned previously in another forum topic, there is really nothing that we can do if your Google Calendar account is experiencing an issue (we can see the successful feed fetches, so can't even guess why your Google Calendar account would be out-of-date; only the Google Calendar team can check that).
I saw that the Google Calendar folks provided details on reporting the iCalendar issue to them. I'm not sure if you heard back from them yet, but I'd suggest sending those same URLs to them and seeing if they can investigate why your Google Calendar account doesn't seem to be up-to-date.
I'm sorry we can't be of more help, but there is nothing further that we can do to help you with this issue from our end.
Thanks for providing the iCalendar URLs privately.
We've checked our servers -- in the last 24hrs, Google Calendar has successfully fetched each of these URLs multiple times (the interval between fetches was between 4 and 8 hours; I've provided exact fetch times via email).
We've also checked to make sure that nothing was cached on our end (i.e. to make sure that when the fetch took place, it always got the latest version of your tasks). All files comply with the iCalendar specification (RFC 2445) for calendar data exchange; there's nothing to suggest why Google Calendar would potentially not update to reflect the latest feed update.
Given that the URLs are being fetched successfully by Google Calendar every 4 to 8 hours, unfortunately the only folks who can tell why your Google Calendar account isn't reflecting those updates are the Google Calendar team.
As I mentioned previously in another forum topic, there is really nothing that we can do if your Google Calendar account is experiencing an issue (we can see the successful feed fetches, so can't even guess why your Google Calendar account would be out-of-date; only the Google Calendar team can check that).
I saw that the Google Calendar folks provided details on reporting the iCalendar issue to them. I'm not sure if you heard back from them yet, but I'd suggest sending those same URLs to them and seeing if they can investigate why your Google Calendar account doesn't seem to be up-to-date.
I'm sorry we can't be of more help, but there is nothing further that we can do to help you with this issue from our end.
joeyahoo says:
Emily,
Thanks for the reply. The logs of Google's fetching schedule are impressive: Google is indeed fetching the ICal feeds every 6 hours like clockwork.
However, If if you think that means everything is fine with RTM and that there's nothing more that can be done to solve the problem, then it doesn't speak well for anyone's troubleshooting skills, or RTM's desire to support a paying customer, or RTM's desire to understand what is really happening here.
Now knowing that Google is fetching the feeds, here's what I think is going on and what we know:
1. Google is getting the feed like clockwork.
2. RTM isn't changing the format or content of the ICS files every day. And...
3. Google (probably) isn't changing its ICS parser every day. Yet...
4. GCal doesn't always update RTM's ICS feeds in the Calendar display.
So what's going on? I think I have a very good guess thanks to your new information:
I bet the Google Calender ICS parser is TIMING OUT on RTM's overly complicated ICS files. Google's server load is probably the variable here. I bet when the instantaneous server load is low, Google's ICS parser is able to get through RTM's ICS file and update the calendar display. I bet when server load is high, the parser isn't able to get through the entire ICS file, and then not doing updates. Then it tries again in 6 hours, when it might make it through, or it might not. Lather, rinse, and repeat.
What do I base this on? Research. I read the iCalendar specification (RFC 2445), specifically looking at all the:
RDATE;VALUE=DATE-TIME:19801026T020000
RDATE;VALUE=DATE-TIME:19811025T020000
RDATE;VALUE=DATE-TIME:19821031T020000
lines in RTM's ICS files.
RDATE is intended to be used for repeating events, yet in the ICS files I posted above, THERE ARE NO REPEATING EVENTS.
It seems that RTM's ICS file has at least 130 extra lines that need to be parsed that seem unnecessary. For example, the Airset ICS file I posted above for the exact same three non-repeating events don't have these lines at all.
In fact, as another test, I created a new RTM account, deleted all tasks, and then grabbed the ICS feed for this zero-item list. Here's what an RTM generated ICS file looks like for a CALENDAR WITH NO EVENTS IN IT:
----------snip------------
BEGIN:VCALENDAR
PRODID:-//Remember The Milk//rtm.Service.iCalendar.Export 3.0//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:PUBLISH
X-WR-CALNAME:Personal
LAST-MODIFIED:20081111T170401Z
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:20070311T020000
RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:20071104T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:STANDARD
TZOFFSETFROM:-0752
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:18831118T120702
RDATE;VALUE=DATE-TIME:18831118T120702
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:19180331T020000
RDATE;VALUE=DATE-TIME:19180331T020000
RDATE;VALUE=DATE-TIME:19190330T020000
RDATE;VALUE=DATE-TIME:19480314T020000
RDATE;VALUE=DATE-TIME:19500430T020000
RDATE;VALUE=DATE-TIME:19510429T020000
RDATE;VALUE=DATE-TIME:19520427T020000
RDATE;VALUE=DATE-TIME:19530426T020000
RDATE;VALUE=DATE-TIME:19540425T020000
RDATE;VALUE=DATE-TIME:19550424T020000
RDATE;VALUE=DATE-TIME:19560429T020000
RDATE;VALUE=DATE-TIME:19570428T020000
RDATE;VALUE=DATE-TIME:19580427T020000
RDATE;VALUE=DATE-TIME:19590426T020000
RDATE;VALUE=DATE-TIME:19600424T020000
RDATE;VALUE=DATE-TIME:19610430T020000
RDATE;VALUE=DATE-TIME:19620429T020000
RDATE;VALUE=DATE-TIME:19630428T020000
RDATE;VALUE=DATE-TIME:19640426T020000
RDATE;VALUE=DATE-TIME:19650425T020000
RDATE;VALUE=DATE-TIME:19660424T020000
RDATE;VALUE=DATE-TIME:19670430T020000
RDATE;VALUE=DATE-TIME:19680428T020000
RDATE;VALUE=DATE-TIME:19690427T020000
RDATE;VALUE=DATE-TIME:19700426T020000
RDATE;VALUE=DATE-TIME:19710425T020000
RDATE;VALUE=DATE-TIME:19720430T020000
RDATE;VALUE=DATE-TIME:19730429T020000
RDATE;VALUE=DATE-TIME:19740106T020000
RDATE;VALUE=DATE-TIME:19750223T020000
RDATE;VALUE=DATE-TIME:19760425T020000
RDATE;VALUE=DATE-TIME:19770424T020000
RDATE;VALUE=DATE-TIME:19780430T020000
RDATE;VALUE=DATE-TIME:19790429T020000
RDATE;VALUE=DATE-TIME:19800427T020000
RDATE;VALUE=DATE-TIME:19810426T020000
RDATE;VALUE=DATE-TIME:19820425T020000
RDATE;VALUE=DATE-TIME:19830424T020000
RDATE;VALUE=DATE-TIME:19840429T020000
RDATE;VALUE=DATE-TIME:19850428T020000
RDATE;VALUE=DATE-TIME:19860427T020000
RDATE;VALUE=DATE-TIME:19870405T020000
RDATE;VALUE=DATE-TIME:19880403T020000
RDATE;VALUE=DATE-TIME:19890402T020000
RDATE;VALUE=DATE-TIME:19900401T020000
RDATE;VALUE=DATE-TIME:19910407T020000
RDATE;VALUE=DATE-TIME:19920405T020000
RDATE;VALUE=DATE-TIME:19930404T020000
RDATE;VALUE=DATE-TIME:19940403T020000
RDATE;VALUE=DATE-TIME:19950402T020000
RDATE;VALUE=DATE-TIME:19960407T020000
RDATE;VALUE=DATE-TIME:19970406T020000
RDATE;VALUE=DATE-TIME:19980405T020000
RDATE;VALUE=DATE-TIME:19990404T020000
RDATE;VALUE=DATE-TIME:20000402T020000
RDATE;VALUE=DATE-TIME:20010401T020000
RDATE;VALUE=DATE-TIME:20020407T020000
RDATE;VALUE=DATE-TIME:20030406T020000
RDATE;VALUE=DATE-TIME:20040404T020000
RDATE;VALUE=DATE-TIME:20050403T020000
RDATE;VALUE=DATE-TIME:20060402T020000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19181027T020000
RDATE;VALUE=DATE-TIME:19181027T020000
RDATE;VALUE=DATE-TIME:19191026T020000
RDATE;VALUE=DATE-TIME:19450930T020000
RDATE;VALUE=DATE-TIME:19490101T020000
RDATE;VALUE=DATE-TIME:19500924T020000
RDATE;VALUE=DATE-TIME:19510930T020000
RDATE;VALUE=DATE-TIME:19520928T020000
RDATE;VALUE=DATE-TIME:19530927T020000
RDATE;VALUE=DATE-TIME:19540926T020000
RDATE;VALUE=DATE-TIME:19550925T020000
RDATE;VALUE=DATE-TIME:19560930T020000
RDATE;VALUE=DATE-TIME:19570929T020000
RDATE;VALUE=DATE-TIME:19580928T020000
RDATE;VALUE=DATE-TIME:19590927T020000
RDATE;VALUE=DATE-TIME:19600925T020000
RDATE;VALUE=DATE-TIME:19610924T020000
RDATE;VALUE=DATE-TIME:19621028T020000
RDATE;VALUE=DATE-TIME:19631027T020000
RDATE;VALUE=DATE-TIME:19641025T020000
RDATE;VALUE=DATE-TIME:19651031T020000
RDATE;VALUE=DATE-TIME:19661030T020000
RDATE;VALUE=DATE-TIME:19671029T020000
RDATE;VALUE=DATE-TIME:19681027T020000
RDATE;VALUE=DATE-TIME:19691026T020000
RDATE;VALUE=DATE-TIME:19701025T020000
RDATE;VALUE=DATE-TIME:19711031T020000
RDATE;VALUE=DATE-TIME:19721029T020000
RDATE;VALUE=DATE-TIME:19731028T020000
RDATE;VALUE=DATE-TIME:19741027T020000
RDATE;VALUE=DATE-TIME:19751026T020000
RDATE;VALUE=DATE-TIME:19761031T020000
RDATE;VALUE=DATE-TIME:19771030T020000
RDATE;VALUE=DATE-TIME:19781029T020000
RDATE;VALUE=DATE-TIME:19791028T020000
RDATE;VALUE=DATE-TIME:19801026T020000
RDATE;VALUE=DATE-TIME:19811025T020000
RDATE;VALUE=DATE-TIME:19821031T020000
RDATE;VALUE=DATE-TIME:19831030T020000
RDATE;VALUE=DATE-TIME:19841028T020000
RDATE;VALUE=DATE-TIME:19851027T020000
RDATE;VALUE=DATE-TIME:19861026T020000
RDATE;VALUE=DATE-TIME:19871025T020000
RDATE;VALUE=DATE-TIME:19881030T020000
RDATE;VALUE=DATE-TIME:19891029T020000
RDATE;VALUE=DATE-TIME:19901028T020000
RDATE;VALUE=DATE-TIME:19911027T020000
RDATE;VALUE=DATE-TIME:19921025T020000
RDATE;VALUE=DATE-TIME:19931031T020000
RDATE;VALUE=DATE-TIME:19941030T020000
RDATE;VALUE=DATE-TIME:19951029T020000
RDATE;VALUE=DATE-TIME:19961027T020000
RDATE;VALUE=DATE-TIME:19971026T020000
RDATE;VALUE=DATE-TIME:19981025T020000
RDATE;VALUE=DATE-TIME:19991031T020000
RDATE;VALUE=DATE-TIME:20001029T020000
RDATE;VALUE=DATE-TIME:20011028T020000
RDATE;VALUE=DATE-TIME:20021027T020000
RDATE;VALUE=DATE-TIME:20031026T020000
RDATE;VALUE=DATE-TIME:20041031T020000
RDATE;VALUE=DATE-TIME:20051030T020000
RDATE;VALUE=DATE-TIME:20061029T020000
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PWT
DTSTART:19420209T020000
RDATE;VALUE=DATE-TIME:19420209T020000
END:DAYLIGHT
BEGIN:DAYLIGHT
TZOFFSETFROM:-0700
TZOFFSETTO:-0700
TZNAME:PPT
DTSTART:19450814T160000
RDATE;VALUE=DATE-TIME:19450814T160000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0800
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19460101T000000
RDATE;VALUE=DATE-TIME:19460101T000000
RDATE;VALUE=DATE-TIME:19670101T000000
END:STANDARD
END:VTIMEZONE
END:VCALENDAR
----------snip------------
This is 197 lines of ICS files that Google Calendar's parser would have to crunch through in order to display NO EVENTS.
I can't possibly be the only person that thinks this is strange.
I have spent 30 minutes this morning Googling for other ICS files around the internet, and I've retrieved them from many colleges, 4 major national newspapers, the federal government, and several state governments.
I've downloaded dozens and looked at them all, and I cannot find a single ICS file that has anything even remotely similar to these lines:
RDATE;VALUE=DATE-TIME:19981025T020000
RDATE;VALUE=DATE-TIME:19991031T020000
RDATE;VALUE=DATE-TIME:20001029T020000
that are in all of the RTM ICS files I look at.
Now I am not saying these lines are totally unnecessary, nor that they must be the cause of the problem. However, when I can't find another ICS file anywhere on the internet that has anything like these lines, it is a pretty straightforward leap to think that they might be contributing to the problem.
Furthermore, maybe Google Calendar can only give so much CPU time to a single user's GCAL account, so if you have many ICAL feeds to display, the additional feeds are contributing to the timeout problem overall. I myself have 8 iCal feeds being poured into my Google Calendar. Maybe the other users having problems with RTM have a similarly large number of ICal feeds in their GCals. Or maybe not, but it's one more thing to look at.
This last idea I can test by creating a new GCAL account and giving it just one of my troublesome RTM ICal Feeds, and seeing how well it updates. I am going to do this now and report back here.
But my investigating this potential workaround doesn't excuse RTM support for researching and explaining the presence of these "RDATE" lines, or the general level of complexity RTM's ICS files seem to have compared to the other ICS files I'm looking at, or simply considering the possibility that maybe there really is RTM can do to help with this problem.
I guarantee you that when your attitude is "there's nothing more we can do," you'll never even be in a position to figure out if there really is a problem, and if there really is something you can do. I guess not only am I seeking a solution, but I am seeking a different attitude as well. I hope it isn't too much to ask for.
Thanks, and as always, I eagerly anticipate your reply.
-Warr
Thanks for the reply. The logs of Google's fetching schedule are impressive: Google is indeed fetching the ICal feeds every 6 hours like clockwork.
However, If if you think that means everything is fine with RTM and that there's nothing more that can be done to solve the problem, then it doesn't speak well for anyone's troubleshooting skills, or RTM's desire to support a paying customer, or RTM's desire to understand what is really happening here.
Now knowing that Google is fetching the feeds, here's what I think is going on and what we know:
1. Google is getting the feed like clockwork.
2. RTM isn't changing the format or content of the ICS files every day. And...
3. Google (probably) isn't changing its ICS parser every day. Yet...
4. GCal doesn't always update RTM's ICS feeds in the Calendar display.
So what's going on? I think I have a very good guess thanks to your new information:
I bet the Google Calender ICS parser is TIMING OUT on RTM's overly complicated ICS files. Google's server load is probably the variable here. I bet when the instantaneous server load is low, Google's ICS parser is able to get through RTM's ICS file and update the calendar display. I bet when server load is high, the parser isn't able to get through the entire ICS file, and then not doing updates. Then it tries again in 6 hours, when it might make it through, or it might not. Lather, rinse, and repeat.
What do I base this on? Research. I read the iCalendar specification (RFC 2445), specifically looking at all the:
RDATE;VALUE=DATE-TIME:19801026T020000
RDATE;VALUE=DATE-TIME:19811025T020000
RDATE;VALUE=DATE-TIME:19821031T020000
lines in RTM's ICS files.
RDATE is intended to be used for repeating events, yet in the ICS files I posted above, THERE ARE NO REPEATING EVENTS.
It seems that RTM's ICS file has at least 130 extra lines that need to be parsed that seem unnecessary. For example, the Airset ICS file I posted above for the exact same three non-repeating events don't have these lines at all.
In fact, as another test, I created a new RTM account, deleted all tasks, and then grabbed the ICS feed for this zero-item list. Here's what an RTM generated ICS file looks like for a CALENDAR WITH NO EVENTS IN IT:
----------snip------------
BEGIN:VCALENDAR
PRODID:-//Remember The Milk//rtm.Service.iCalendar.Export 3.0//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:PUBLISH
X-WR-CALNAME:Personal
LAST-MODIFIED:20081111T170401Z
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:20070311T020000
RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:20071104T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:STANDARD
TZOFFSETFROM:-0752
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:18831118T120702
RDATE;VALUE=DATE-TIME:18831118T120702
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:19180331T020000
RDATE;VALUE=DATE-TIME:19180331T020000
RDATE;VALUE=DATE-TIME:19190330T020000
RDATE;VALUE=DATE-TIME:19480314T020000
RDATE;VALUE=DATE-TIME:19500430T020000
RDATE;VALUE=DATE-TIME:19510429T020000
RDATE;VALUE=DATE-TIME:19520427T020000
RDATE;VALUE=DATE-TIME:19530426T020000
RDATE;VALUE=DATE-TIME:19540425T020000
RDATE;VALUE=DATE-TIME:19550424T020000
RDATE;VALUE=DATE-TIME:19560429T020000
RDATE;VALUE=DATE-TIME:19570428T020000
RDATE;VALUE=DATE-TIME:19580427T020000
RDATE;VALUE=DATE-TIME:19590426T020000
RDATE;VALUE=DATE-TIME:19600424T020000
RDATE;VALUE=DATE-TIME:19610430T020000
RDATE;VALUE=DATE-TIME:19620429T020000
RDATE;VALUE=DATE-TIME:19630428T020000
RDATE;VALUE=DATE-TIME:19640426T020000
RDATE;VALUE=DATE-TIME:19650425T020000
RDATE;VALUE=DATE-TIME:19660424T020000
RDATE;VALUE=DATE-TIME:19670430T020000
RDATE;VALUE=DATE-TIME:19680428T020000
RDATE;VALUE=DATE-TIME:19690427T020000
RDATE;VALUE=DATE-TIME:19700426T020000
RDATE;VALUE=DATE-TIME:19710425T020000
RDATE;VALUE=DATE-TIME:19720430T020000
RDATE;VALUE=DATE-TIME:19730429T020000
RDATE;VALUE=DATE-TIME:19740106T020000
RDATE;VALUE=DATE-TIME:19750223T020000
RDATE;VALUE=DATE-TIME:19760425T020000
RDATE;VALUE=DATE-TIME:19770424T020000
RDATE;VALUE=DATE-TIME:19780430T020000
RDATE;VALUE=DATE-TIME:19790429T020000
RDATE;VALUE=DATE-TIME:19800427T020000
RDATE;VALUE=DATE-TIME:19810426T020000
RDATE;VALUE=DATE-TIME:19820425T020000
RDATE;VALUE=DATE-TIME:19830424T020000
RDATE;VALUE=DATE-TIME:19840429T020000
RDATE;VALUE=DATE-TIME:19850428T020000
RDATE;VALUE=DATE-TIME:19860427T020000
RDATE;VALUE=DATE-TIME:19870405T020000
RDATE;VALUE=DATE-TIME:19880403T020000
RDATE;VALUE=DATE-TIME:19890402T020000
RDATE;VALUE=DATE-TIME:19900401T020000
RDATE;VALUE=DATE-TIME:19910407T020000
RDATE;VALUE=DATE-TIME:19920405T020000
RDATE;VALUE=DATE-TIME:19930404T020000
RDATE;VALUE=DATE-TIME:19940403T020000
RDATE;VALUE=DATE-TIME:19950402T020000
RDATE;VALUE=DATE-TIME:19960407T020000
RDATE;VALUE=DATE-TIME:19970406T020000
RDATE;VALUE=DATE-TIME:19980405T020000
RDATE;VALUE=DATE-TIME:19990404T020000
RDATE;VALUE=DATE-TIME:20000402T020000
RDATE;VALUE=DATE-TIME:20010401T020000
RDATE;VALUE=DATE-TIME:20020407T020000
RDATE;VALUE=DATE-TIME:20030406T020000
RDATE;VALUE=DATE-TIME:20040404T020000
RDATE;VALUE=DATE-TIME:20050403T020000
RDATE;VALUE=DATE-TIME:20060402T020000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19181027T020000
RDATE;VALUE=DATE-TIME:19181027T020000
RDATE;VALUE=DATE-TIME:19191026T020000
RDATE;VALUE=DATE-TIME:19450930T020000
RDATE;VALUE=DATE-TIME:19490101T020000
RDATE;VALUE=DATE-TIME:19500924T020000
RDATE;VALUE=DATE-TIME:19510930T020000
RDATE;VALUE=DATE-TIME:19520928T020000
RDATE;VALUE=DATE-TIME:19530927T020000
RDATE;VALUE=DATE-TIME:19540926T020000
RDATE;VALUE=DATE-TIME:19550925T020000
RDATE;VALUE=DATE-TIME:19560930T020000
RDATE;VALUE=DATE-TIME:19570929T020000
RDATE;VALUE=DATE-TIME:19580928T020000
RDATE;VALUE=DATE-TIME:19590927T020000
RDATE;VALUE=DATE-TIME:19600925T020000
RDATE;VALUE=DATE-TIME:19610924T020000
RDATE;VALUE=DATE-TIME:19621028T020000
RDATE;VALUE=DATE-TIME:19631027T020000
RDATE;VALUE=DATE-TIME:19641025T020000
RDATE;VALUE=DATE-TIME:19651031T020000
RDATE;VALUE=DATE-TIME:19661030T020000
RDATE;VALUE=DATE-TIME:19671029T020000
RDATE;VALUE=DATE-TIME:19681027T020000
RDATE;VALUE=DATE-TIME:19691026T020000
RDATE;VALUE=DATE-TIME:19701025T020000
RDATE;VALUE=DATE-TIME:19711031T020000
RDATE;VALUE=DATE-TIME:19721029T020000
RDATE;VALUE=DATE-TIME:19731028T020000
RDATE;VALUE=DATE-TIME:19741027T020000
RDATE;VALUE=DATE-TIME:19751026T020000
RDATE;VALUE=DATE-TIME:19761031T020000
RDATE;VALUE=DATE-TIME:19771030T020000
RDATE;VALUE=DATE-TIME:19781029T020000
RDATE;VALUE=DATE-TIME:19791028T020000
RDATE;VALUE=DATE-TIME:19801026T020000
RDATE;VALUE=DATE-TIME:19811025T020000
RDATE;VALUE=DATE-TIME:19821031T020000
RDATE;VALUE=DATE-TIME:19831030T020000
RDATE;VALUE=DATE-TIME:19841028T020000
RDATE;VALUE=DATE-TIME:19851027T020000
RDATE;VALUE=DATE-TIME:19861026T020000
RDATE;VALUE=DATE-TIME:19871025T020000
RDATE;VALUE=DATE-TIME:19881030T020000
RDATE;VALUE=DATE-TIME:19891029T020000
RDATE;VALUE=DATE-TIME:19901028T020000
RDATE;VALUE=DATE-TIME:19911027T020000
RDATE;VALUE=DATE-TIME:19921025T020000
RDATE;VALUE=DATE-TIME:19931031T020000
RDATE;VALUE=DATE-TIME:19941030T020000
RDATE;VALUE=DATE-TIME:19951029T020000
RDATE;VALUE=DATE-TIME:19961027T020000
RDATE;VALUE=DATE-TIME:19971026T020000
RDATE;VALUE=DATE-TIME:19981025T020000
RDATE;VALUE=DATE-TIME:19991031T020000
RDATE;VALUE=DATE-TIME:20001029T020000
RDATE;VALUE=DATE-TIME:20011028T020000
RDATE;VALUE=DATE-TIME:20021027T020000
RDATE;VALUE=DATE-TIME:20031026T020000
RDATE;VALUE=DATE-TIME:20041031T020000
RDATE;VALUE=DATE-TIME:20051030T020000
RDATE;VALUE=DATE-TIME:20061029T020000
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PWT
DTSTART:19420209T020000
RDATE;VALUE=DATE-TIME:19420209T020000
END:DAYLIGHT
BEGIN:DAYLIGHT
TZOFFSETFROM:-0700
TZOFFSETTO:-0700
TZNAME:PPT
DTSTART:19450814T160000
RDATE;VALUE=DATE-TIME:19450814T160000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0800
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19460101T000000
RDATE;VALUE=DATE-TIME:19460101T000000
RDATE;VALUE=DATE-TIME:19670101T000000
END:STANDARD
END:VTIMEZONE
END:VCALENDAR
----------snip------------
This is 197 lines of ICS files that Google Calendar's parser would have to crunch through in order to display NO EVENTS.
I can't possibly be the only person that thinks this is strange.
I have spent 30 minutes this morning Googling for other ICS files around the internet, and I've retrieved them from many colleges, 4 major national newspapers, the federal government, and several state governments.
I've downloaded dozens and looked at them all, and I cannot find a single ICS file that has anything even remotely similar to these lines:
RDATE;VALUE=DATE-TIME:19981025T020000
RDATE;VALUE=DATE-TIME:19991031T020000
RDATE;VALUE=DATE-TIME:20001029T020000
that are in all of the RTM ICS files I look at.
Now I am not saying these lines are totally unnecessary, nor that they must be the cause of the problem. However, when I can't find another ICS file anywhere on the internet that has anything like these lines, it is a pretty straightforward leap to think that they might be contributing to the problem.
Furthermore, maybe Google Calendar can only give so much CPU time to a single user's GCAL account, so if you have many ICAL feeds to display, the additional feeds are contributing to the timeout problem overall. I myself have 8 iCal feeds being poured into my Google Calendar. Maybe the other users having problems with RTM have a similarly large number of ICal feeds in their GCals. Or maybe not, but it's one more thing to look at.
This last idea I can test by creating a new GCAL account and giving it just one of my troublesome RTM ICal Feeds, and seeing how well it updates. I am going to do this now and report back here.
But my investigating this potential workaround doesn't excuse RTM support for researching and explaining the presence of these "RDATE" lines, or the general level of complexity RTM's ICS files seem to have compared to the other ICS files I'm looking at, or simply considering the possibility that maybe there really is RTM can do to help with this problem.
I guarantee you that when your attitude is "there's nothing more we can do," you'll never even be in a position to figure out if there really is a problem, and if there really is something you can do. I guess not only am I seeking a solution, but I am seeking a different attitude as well. I hope it isn't too much to ask for.
Thanks, and as always, I eagerly anticipate your reply.
-Warr
wernst says:
Whoops. It should now be obvious that the "joeyahoo" account (which I used to create a new test I just wrote about) is actually me, wernst.
-Warr
-Warr
emily (Remember The Milk) says:
Google Calendar is not timing out in any way when fetching the iCalendar files, and the iCalendar files are correct and contain as much information as is necessary (for anyone curious, those lines describe the timezone; extremely important for ensuring your tasks display at the correct time!). All your feeds are standard, valid iCalendar files.
As described above, Google Calendar is correctly fetching these standard iCalendar feeds from RTM at regular intervals. We have done everything that we can on our end to investigate this issue -- we have ensured that the feeds are valid and working correctly, and that Google Calendar is successfully fetching them.
If you're experiencing a problem with the Google Calendar application not reflecting updates to the feeds in your Google Calendar account, you will need to contact the Google Calendar team as they are the only folks who can help with this issue.
As there are no issues on the Remember The Milk side, I cannot provide you with any further support regarding this issue.
As described above, Google Calendar is correctly fetching these standard iCalendar feeds from RTM at regular intervals. We have done everything that we can on our end to investigate this issue -- we have ensured that the feeds are valid and working correctly, and that Google Calendar is successfully fetching them.
If you're experiencing a problem with the Google Calendar application not reflecting updates to the feeds in your Google Calendar account, you will need to contact the Google Calendar team as they are the only folks who can help with this issue.
As there are no issues on the Remember The Milk side, I cannot provide you with any further support regarding this issue.
wernst says:
Emily,
Thanks for your explanation and your patience. You've indulged my curiosity a great deal, and I'm very appreciative.
Please note that I haven't been suggesting GCal is timing out when *fetching* the feeds (thanks to your efforts, that's been ruled out). I'm suggesting that GCal is timing out when *parsing and rendering* the feeds once they have been downloaded.
I'm suggesting that RTM's ICS files are overly complex, including information (about timezones, apparently) that *no other* ics provider seems to need to include for events to appear at the correct time. As an example, the Airset ICS files display events at the same time as the RTM ICS files, despite not having this "critical" timezone information embedded.
At any rate, I now understand that the discussion is closed. Again, thanks for your explanations.
And to Michael, who started this thread - I hope you have greater understanding of the problem, and a potential solution (that is, use Airset to grab your RTM feeds, simplify them, and then publish new ones at a different URL that GCal can then grab without cholking.)
-Warr
Thanks for your explanation and your patience. You've indulged my curiosity a great deal, and I'm very appreciative.
Please note that I haven't been suggesting GCal is timing out when *fetching* the feeds (thanks to your efforts, that's been ruled out). I'm suggesting that GCal is timing out when *parsing and rendering* the feeds once they have been downloaded.
I'm suggesting that RTM's ICS files are overly complex, including information (about timezones, apparently) that *no other* ics provider seems to need to include for events to appear at the correct time. As an example, the Airset ICS files display events at the same time as the RTM ICS files, despite not having this "critical" timezone information embedded.
At any rate, I now understand that the discussion is closed. Again, thanks for your explanations.
And to Michael, who started this thread - I hope you have greater understanding of the problem, and a potential solution (that is, use Airset to grab your RTM feeds, simplify them, and then publish new ones at a different URL that GCal can then grab without cholking.)
-Warr
(closed account) says:
Wernst-
If you look at the IETF RFC (https://www.ietf.org/rfc/rfc2445.txt) and read the section on timezones you'll see what those things are for. For some reason RTM is embedding the start times of daylight savings and standard time going all the way back to 1918. According to the RFC this is legal. Whether it is a good idea or not is questionable. There is no benefit for having that information embedded in the feed. Nobody cares that Pacific Standard Time in 1918 started on 10/27 at 2AM (RDATE;VALUE=DATE-TIME:19181027T020000 ) because nobody is putting in events for 1918 into their todo lists (unless someone invented a time machine and it wasn't reported anywhere).
However Emily's point of "As there are no issues on the Remember The Milk side..." is totally ridiculous. There are definite issues with those feeds. The iCal data can easily be simplified as it is excessive. And obviously they are doing something odd if google calendar isn't working right all the time yet the same feed coming from AirSet is. Emily....it may be legal syntax....that doesn't mean it's a good idea.
To quote you:
"As described above, Google Calendar is correctly fetching these standard iCalendar feeds from RTM at regular intervals. We have done everything that we can on our end to investigate this issue -- we have ensured that the feeds are valid and working correctly, and that Google Calendar is successfully fetching them."
The feeds are valid but they're *not* working correctly on the other end. I'd argue that someone hasn't done everything to investigate. Investigate why you are embedding ridiculous amounts of timezone information into a feed with no events that needs none of it. You've had a paying customer do a lot of good investigative legwork for you. Take advantage of it. Please.
If you look at the IETF RFC (https://www.ietf.org/rfc/rfc2445.txt) and read the section on timezones you'll see what those things are for. For some reason RTM is embedding the start times of daylight savings and standard time going all the way back to 1918. According to the RFC this is legal. Whether it is a good idea or not is questionable. There is no benefit for having that information embedded in the feed. Nobody cares that Pacific Standard Time in 1918 started on 10/27 at 2AM (RDATE;VALUE=DATE-TIME:19181027T020000 ) because nobody is putting in events for 1918 into their todo lists (unless someone invented a time machine and it wasn't reported anywhere).
However Emily's point of "As there are no issues on the Remember The Milk side..." is totally ridiculous. There are definite issues with those feeds. The iCal data can easily be simplified as it is excessive. And obviously they are doing something odd if google calendar isn't working right all the time yet the same feed coming from AirSet is. Emily....it may be legal syntax....that doesn't mean it's a good idea.
To quote you:
"As described above, Google Calendar is correctly fetching these standard iCalendar feeds from RTM at regular intervals. We have done everything that we can on our end to investigate this issue -- we have ensured that the feeds are valid and working correctly, and that Google Calendar is successfully fetching them."
The feeds are valid but they're *not* working correctly on the other end. I'd argue that someone hasn't done everything to investigate. Investigate why you are embedding ridiculous amounts of timezone information into a feed with no events that needs none of it. You've had a paying customer do a lot of good investigative legwork for you. Take advantage of it. Please.
emily (Remember The Milk) says:
Thanks Warr -- I'm sorry there wasn't anything futher that could be done from our end to help with your issue. :( As I said before, I'd recommend contacting the Google Calendar team, as I'm sure they'd wish to investigate if anything in your Google Calendar account isn't updating correctly.
To jkratz:
All iCalendar feeds are standard, valid iCalendar files.
As established above, other services (including Google Calendar) are correctly fetching these files.
If you're experiencing a problem with a particular third-party service showing you updates within their application, please contact that third-party as there is nothing we can do to help you.
This discussion is now closed.
To jkratz:
All iCalendar feeds are standard, valid iCalendar files.
As established above, other services (including Google Calendar) are correctly fetching these files.
If you're experiencing a problem with a particular third-party service showing you updates within their application, please contact that third-party as there is nothing we can do to help you.
This discussion is now closed.