We've been getting sporadic reports of recurrences being moved by gCal to a different startTime. This morning I was able to reproduce this, but only intermittently:
- I created the following entry (using the API with raw HTTP requests): <entry xmlns='http://www.w3.org/2005/Atom' xmlns:gd='http://schemas.google.com/g/2005' xmlns:gCal='http://schemas.google.com/gCal/2005'> <gd:recurrence>DTSTART;TZID=America/Chicago:20061231T050000 DURATION:PT3600S RRULE:FREQ=DAILY;INTERVAL=1</gd:recurrence> - It showed up in gCal as beginning at 0400 local time, not 0500 - I verified that the calendar and my gCal "current timezone" were both set to America/Chicago
- Then I tried to reproduce the problem using the exact same code, but with a new startTime (same day, different time). The new event showed up fine.
- So I ran the same code 10 more times (using a fresh session each time), each time with an identical recurrence other than the startTime hour. - 2 out of 10 recurrences were offset in gCal by -1 hour. The other 8 were fine.
Note that I don't know if the 1-hour offset is a constant, or if it's based on my timezone. One of our users reporting seeing events that were set to occur in the MST timezone, even though he's in EST, and all of his personal and calendar settings are set to EST. However, in each of my 10 test cases, the calendar in question was listed in the metafeed as having the same timezone: America/Chicago.
Anyway, this appears to be easily reproducible for me. Please let me know if I can provide any more detail that will help you guys track down the problem.
Thank you very much Charlie for the report and detailed debugging work. Thanks also for the offer to provide more detail -- I have limited bandwidth right now, but will attempt to recreate the problem shortly and let you know if there's any issues doing that.
I tested this out, but wasn't able to recreate it.
I set the timezone of my calendar to Central. I set the timezone in the UI (settings, general) to Central as well. I verified that the feed timezone was America/Chicago I added the event with the following recurrence spec: recur = "DTSTART;TZID=America/Chicago:20061231T050000" + crlf + "DURATION:PT3600S" + crlf + "RRULE:FREQ=DAILY;INTERVAL=1";
The event repeatedly added at 5am on my calendar (10 times), though I did see the 'Failed to process recurrence rule' error on occassion.
I will try and run it some more times to see if that has any effect. Can you verify the time zones set on the calendar and in the UI?
Also, what times besides 0500 did you try? Can you send me (privately if you wish) the calendar address usern...@domain.tld or calen...@group.calendar.google.com?
I tested this out, but wasn't able to recreate it.
I set the timezone of my calendar to Central. I set the timezone in the UI (settings, general) to Central as well. I verified that the feed timezone was America/Chicago I added the event with the following recurrence spec: recur = "DTSTART;TZID=America/Chicago:20061231T050000" + crlf + "DURATION:PT3600S" + crlf + "RRULE:FREQ=DAILY;INTERVAL=1";
The event repeatedly added at 5am on my calendar (10 times), though I did see the 'Failed to process recurrence rule' error on occassion.
I will try and run it some more times to see if that has any effect. Can you verify the time zones set on the calendar and in the UI?
Also, what times besides 0500 did you try? Can you send me (privately if you wish) the calendar address usern...@domain.tld or calen...@group.calendar.google.com?
I verified that the timezones on the UI and the calendar are both set to "(GMT-06:00) Central Time".
This morning, I tried recurrences starting at 0100, 0200, 0300, etc., through 1000 (local time). Two of them go offset back an hour: the one at 0200 and another one I don't remember.
I just ran the test again and got the same result--2 our of 10 recurrences got pushed back 1 hour. But they're not at the same start times as the ones this morning. This time they're at 0600 and 0900.
This is all on my default calendar (for charlie.w...@gmail.com). I'll leave the events in there for now so you can check it out if you can get to them.
I think I accidently hit 'Reply to author' on this one.
I have been able to successfully recreate this issue -- thanks to Charlie and all the information he provided.
While we will work to resolve this issue on our side, I did notice during my testing that there is a way for the client to check whether the event was properly created. The gd:recurrence element in the response does include an incorrect value for those times when the time for the event is offset.
For instance, after submitting the following: DTSTART;TZID=America/Chicago:20061231T080000 the following was returned: DTSTART;TZID=America/Chicago:20061231T070000
If you wish to handle this issue before the bug is resolved, you could look at the resulting gd:recurrence element and edit the event if necessary.
Thanks, Ryan. I'm hesitant to write the workaround code, knowing that the bug will be fixed. But if it's going to be a while (weeks) before it is, I'll go ahead and do so. Can you hazard a guess as to when that might be? (Hours/days/weeks/fortnights?)
I'd like to update our QA team to be aware of this issue, can you provide any guidance regarding what factors are involved in the manifestation of these recurrence issues?
Any and all recurring events, specific TZ/times...
Ryan Boyd (Google) wrote: > I think I accidently hit 'Reply to author' on this one.
> I have been able to successfully recreate this issue -- thanks to > Charlie and all the information he provided.
> While we will work to resolve this issue on our side, I did notice > during my testing that there is a way for the client to check whether > the event was properly created. The gd:recurrence element in the > response does include an incorrect value for those times when the time > for the event is offset.
> For instance, after submitting the following: > DTSTART;TZID=America/Chicago:20061231T080000 > the following was returned: > DTSTART;TZID=America/Chicago:20061231T070000
> If you wish to handle this issue before the bug is resolved, you could > look at the resulting gd:recurrence element and edit the event if > necessary.
We haen't found the exact cause yet, so I can only give you guidance from my tests.
With the given syntax, for doing a recurring even that repeats daily for an indefinite period of time and lasts 60 minutes, I am able to reproduce this with at least 4 different hours with the 12312006 start date and using the US Central timezone (America/Chicago).
I was able to produce this on between 1 and 3 times out of 20 requests in each batch run.
I'll post to the groups when I have more information about this bug.
Cheers,
-Ryan
On Jan 4, 9:20 am, "Derek" <derek.tin...@timesearchinc.com> wrote:
> I'd like to update our QA team to be aware of this issue, can you > provide any guidance regarding what factors are involved in the > manifestation of these recurrence issues?
> Any and all recurring events, specific TZ/times...
> Ryan Boyd (Google) wrote: > > I think I accidently hit 'Reply to author' on this one.
> > I have been able to successfully recreate this issue -- thanks to > > Charlie and all the information he provided.
> > While we will work to resolve this issue on our side, I did notice > > during my testing that there is a way for the client to check whether > > the event was properly created. The gd:recurrence element in the > > response does include an incorrect value for those times when the time > > for the event is offset.
> > For instance, after submitting the following: > > DTSTART;TZID=America/Chicago:20061231T080000 > > the following was returned: > > DTSTART;TZID=America/Chicago:20061231T070000
> > If you wish to handle this issue before the bug is resolved, you could > > look at the resulting gd:recurrence element and edit the event if > > necessary.
> We haen't found the exact cause yet, so I can only give you guidance > from my tests.
> With the given syntax, for doing a recurring even that repeats daily > for an indefinite period of time and lasts 60 minutes, I am able to > reproduce this with at least 4 different hours with the 12312006 start > date and using the US Central timezone (America/Chicago).
> I was able to produce this on between 1 and 3 times out of 20 requests > in each batch run.
> I'll post to the groups when I have more information about this bug.
> Cheers,
> -Ryan
> On Jan 4, 9:20 am, "Derek" <derek.tin...@timesearchinc.com> wrote:
> > Thanks Ryan and Charlie.
> > I'd like to update our QA team to be aware of this issue, can you > > provide any guidance regarding what factors are involved in the > > manifestation of these recurrence issues?
> > Any and all recurring events, specific TZ/times...
> > Ryan Boyd (Google) wrote: > > > I think I accidently hit 'Reply to author' on this one.
> > > I have been able to successfully recreate this issue -- thanks to > > > Charlie and all the information he provided.
> > > While we will work to resolve this issue on our side, I did notice > > > during my testing that there is a way for the client to check whether > > > the event was properly created. The gd:recurrence element in the > > > response does include an incorrect value for those times when the time > > > for the event is offset.
> > > For instance, after submitting the following: > > > DTSTART;TZID=America/Chicago:20061231T080000 > > > the following was returned: > > > DTSTART;TZID=America/Chicago:20061231T070000
> > > If you wish to handle this issue before the bug is resolved, you could > > > look at the resulting gd:recurrence element and edit the event if > > > necessary.
> On Jan 5, 10:51 am, "Ryan Boyd (Google)" <api.rb...@google.com> wrote: > > Hi Derek,
> > We haen't found the exact cause yet, so I can only give you guidance > > from my tests.
> > With the given syntax, for doing a recurring even that repeats daily > > for an indefinite period of time and lasts 60 minutes, I am able to > > reproduce this with at least 4 different hours with the 12312006 start > > date and using the US Central timezone (America/Chicago).
> > I was able to produce this on between 1 and 3 times out of 20 requests > > in each batch run.
> > I'll post to the groups when I have more information about this bug.
> > Cheers,
> > -Ryan
> > On Jan 4, 9:20 am, "Derek" <derek.tin...@timesearchinc.com> wrote:
> > > Thanks Ryan and Charlie.
> > > I'd like to update our QA team to be aware of this issue, can you > > > provide any guidance regarding what factors are involved in the > > > manifestation of these recurrence issues?
> > > Any and all recurring events, specific TZ/times...
> > > Ryan Boyd (Google) wrote: > > > > I think I accidently hit 'Reply to author' on this one.
> > > > I have been able to successfully recreate this issue -- thanks to > > > > Charlie and all the information he provided.
> > > > While we will work to resolve this issue on our side, I did notice > > > > during my testing that there is a way for the client to check > whether > > > > the event was properly created. The gd:recurrence element in the > > > > response does include an incorrect value for those times when the > time > > > > for the event is offset.
> > > > For instance, after submitting the following: > > > > DTSTART;TZID=America/Chicago:20061231T080000 > > > > the following was returned: > > > > DTSTART;TZID=America/Chicago:20061231T070000
> > > > If you wish to handle this issue before the bug is resolved, you > could > > > > look at the resulting gd:recurrence element and edit the event if > > > > necessary.
I also got this problem today morning. My Outlook and Google TimeZones are both at GMT -5:00 EST. One of my Outlook Recurring event was at 9:00 AM of duration 30 minutes. It was created in Google at 8:00 AM instead. Other recurring events in the Outlook Calendar were at the right time in Google.
When i updated my Oultook event and pushed in Google again, the wrong event was shifted to right time. I think the time shiftin of -1 hour occurs only while adding the events in Google calendar.
Any ideas ?
On Feb 9, 6:55 pm, "Ryan Boyd (Google)" <api.rb...@google.com> wrote:
> We are aware of and can reproduce the problem. We are working on fixing it, > but unfortunately I can't give a timeframe.
> Thanks for the reminder.
> Cheers, > -Ryan
> On 2/8/07, Charlie Wood <charlie.w...@gmail.com> wrote:
> > Ryan,
> > I'm still seeing this behavior. Any news?
> > Thanks, > > Charlie
> > On Jan 5, 10:51 am, "Ryan Boyd (Google)" <api.rb...@google.com> wrote: > > > Hi Derek,
> > > We haen't found the exact cause yet, so I can only give you guidance > > > from my tests.
> > > With the given syntax, for doing a recurring even that repeats daily > > > for an indefinite period of time and lasts 60 minutes, I am able to > > > reproduce this with at least 4 different hours with the 12312006 start > > > date and using the US Central timezone (America/Chicago).
> > > I was able to produce this on between 1 and 3 times out of 20 requests > > > in each batch run.
> > > I'll post to the groups when I have more information about this bug.
> > > Cheers,
> > > -Ryan
> > > On Jan 4, 9:20 am, "Derek" <derek.tin...@timesearchinc.com> wrote:
> > > > Thanks Ryan and Charlie.
> > > > I'd like to update our QA team to be aware of this issue, can you > > > > provide any guidance regarding what factors are involved in the > > > > manifestation of these recurrence issues?
> > > > Any and all recurring events, specific TZ/times...
> > > > Ryan Boyd (Google) wrote: > > > > > I think I accidently hit 'Reply to author' on this one.
> > > > > I have been able to successfully recreate this issue -- thanks to > > > > > Charlie and all the information he provided.
> > > > > While we will work to resolve this issue on our side, I did notice > > > > > during my testing that there is a way for the client to check > > whether > > > > > the event was properly created. The gd:recurrence element in the > > > > > response does include an incorrect value for those times when the > > time > > > > > for the event is offset.
> > > > > For instance, after submitting the following: > > > > > DTSTART;TZID=America/Chicago:20061231T080000 > > > > > the following was returned: > > > > > DTSTART;TZID=America/Chicago:20061231T070000
> > > > > If you wish to handle this issue before the bug is resolved, you > > could > > > > > look at the resulting gd:recurrence element and edit the event if > > > > > necessary.
Yes, we have tracked down the bug and are working on resolving it. Unfortunately, it's not as simple of a fix as it sounds, so I can't give any timeline for resolution.
I'll post a note to the group when this is resolved.
Thanks again,
-Ryan
On 2/15/07, kulvinder_i...@yahoo.com <kulvinder_i...@yahoo.com> wrote:
> I also got this problem today morning. My Outlook and Google TimeZones > are both at GMT -5:00 EST. One of my Outlook Recurring event was at > 9:00 AM of duration 30 minutes. It was created in Google at 8:00 AM > instead. Other recurring events in the Outlook Calendar were at the > right time in Google.
> When i updated my Oultook event and pushed in Google again, the wrong > event was shifted to right time. I think the time shiftin of -1 hour > occurs only while adding the events in Google calendar.
> Any ideas ?
> On Feb 9, 6:55 pm, "Ryan Boyd (Google)" <api.rb...@google.com> wrote: > > Hi Charlie,
> > We are aware of and can reproduce the problem. We are working on fixing > it, > > but unfortunately I can't give a timeframe.
> > Thanks for the reminder.
> > Cheers, > > -Ryan
> > On 2/8/07, Charlie Wood <charlie.w...@gmail.com> wrote:
> > > Ryan,
> > > I'm still seeing this behavior. Any news?
> > > Thanks, > > > Charlie
> > > On Jan 5, 10:51 am, "Ryan Boyd (Google)" <api.rb...@google.com> wrote: > > > > Hi Derek,
> > > > We haen't found the exact cause yet, so I can only give you guidance > > > > from my tests.
> > > > With the given syntax, for doing a recurring even that repeats daily > > > > for an indefinite period of time and lasts 60 minutes, I am able to > > > > reproduce this with at least 4 different hours with the 12312006 > start > > > > date and using the US Central timezone (America/Chicago).
> > > > I was able to produce this on between 1 and 3 times out of 20 > requests > > > > in each batch run.
> > > > I'll post to the groups when I have more information about this bug.
> > > > Cheers,
> > > > -Ryan
> > > > On Jan 4, 9:20 am, "Derek" <derek.tin...@timesearchinc.com> wrote:
> > > > > Thanks Ryan and Charlie.
> > > > > I'd like to update our QA team to be aware of this issue, can you > > > > > provide any guidance regarding what factors are involved in the > > > > > manifestation of these recurrence issues?
> > > > > Any and all recurring events, specific TZ/times...
> > > > > Ryan Boyd (Google) wrote: > > > > > > I think I accidently hit 'Reply to author' on this one.
> > > > > > I have been able to successfully recreate this issue -- thanks > to > > > > > > Charlie and all the information he provided.
> > > > > > While we will work to resolve this issue on our side, I did > notice > > > > > > during my testing that there is a way for the client to check > > > whether > > > > > > the event was properly created. The gd:recurrence element in > the > > > > > > response does include an incorrect value for those times when > the > > > time > > > > > > for the event is offset.
> > > > > > For instance, after submitting the following: > > > > > > DTSTART;TZID=America/Chicago:20061231T080000 > > > > > > the following was returned: > > > > > > DTSTART;TZID=America/Chicago:20061231T070000
> > > > > > If you wish to handle this issue before the bug is resolved, you > > > could > > > > > > look at the resulting gd:recurrence element and edit the event > if > > > > > > necessary.
FWIW I've been seeing this sporadic off-by-one-hour behavior also on other Google services, most notably Search History and Blogger. However the time error seen in those two services has been one hour ahead instead of one hour behind as Kulvinder described. -dave
On Feb 15, 3:16 pm, "Ryan Boyd (Google)" <api.rb...@google.com> wrote:
> Yes, we have tracked down the bug and are working on resolving it. > Unfortunately, it's not as simple of a fix as it sounds, so I can't give any > timeline for resolution.
> I'll post a note to the group when this is resolved.
> Thanks again,
> -Ryan
> On 2/15/07, kulvinder_i...@yahoo.com <kulvinder_i...@yahoo.com> wrote:
> > Hi Ryan,
> > I also got this problem today morning. My Outlook and Google TimeZones > > are both at GMT -5:00 EST. One of my Outlook Recurring event was at > > 9:00 AM of duration 30 minutes. It was created in Google at 8:00 AM > > instead. Other recurring events in the Outlook Calendar were at the > > right time in Google.
> > When i updated my Oultook event and pushed in Google again, the wrong > > event was shifted to right time. I think the time shiftin of -1 hour > > occurs only while adding the events in Google calendar.
> > Any ideas ?
> > On Feb 9, 6:55 pm, "Ryan Boyd (Google)" <api.rb...@google.com> wrote: > > > Hi Charlie,
> > > We are aware of and can reproduce the problem. We are working on fixing > > it, > > > but unfortunately I can't give a timeframe.
> > > Thanks for the reminder.
> > > Cheers, > > > -Ryan
> > > On 2/8/07, Charlie Wood <charlie.w...@gmail.com> wrote:
> > > > Ryan,
> > > > I'm still seeing this behavior. Any news?
> > > > Thanks, > > > > Charlie
> > > > On Jan 5, 10:51 am, "Ryan Boyd (Google)" <api.rb...@google.com> wrote: > > > > > Hi Derek,
> > > > > We haen't found the exact cause yet, so I can only give you guidance > > > > > from my tests.
> > > > > With the given syntax, for doing a recurring even that repeats daily > > > > > for an indefinite period of time and lasts 60 minutes, I am able to> > > > reproduce this with at least 4 different hours with the12312006 > > start > > > > > date and using the US Central timezone (America/Chicago).
> > > > > I was able to produce this on between 1 and 3 times out of 20 > > requests > > > > > in each batch run.
> > > > > I'll post to the groups when I have more information about this bug.
> > > > > Cheers,
> > > > > -Ryan
> > > > > On Jan 4, 9:20 am, "Derek" <derek.tin...@timesearchinc.com> wrote:
> > > > > > Thanks Ryan and Charlie.
> > > > > > I'd like to update our QA team to be aware of this issue, can you > > > > > > provide any guidance regarding what factors are involved in the > > > > > > manifestation of these recurrence issues?
> > > > > > Any and all recurring events, specific TZ/times...
> > > > > > Ryan Boyd (Google) wrote: > > > > > > > I think I accidently hit 'Reply to author' on this one.
> > > > > > > I have been able to successfully recreate this issue -- thanks > > to > > > > > > > Charlie and all the information he provided.
> > > > > > > While we will work to resolve this issue on our side, I did > > notice > > > > > > > during my testing that there is a way for the client to check > > > > whether > > > > > > > the event was properly created. The gd:recurrence element in > > the > > > > > > > response does include an incorrect value for those times when > > the > > > > time > > > > > > > for the event is offset.
> > > > > > > For instance, after submitting the following: > > > > > > > DTSTART;TZID=America/Chicago:20061231T080000 > > > > > > > the following was returned: > > > > > > > DTSTART;TZID=America/Chicago:20061231T070000
> > > > > > > If you wish to handle this issue before the bug is resolved, you > > > > could > > > > > > > look at the resulting gd:recurrence element and edit the event > > if > > > > > > > necessary.
Interesting! Maybe some day Ryan and Frank will describe for us how the gCal back-end works. Until then I find it useful to consider it mysterious and mystical.
:-) -c
On Feb 16, 9:32 am, "dave" <davekamin...@gmail.com> wrote:
> FWIW I've been seeing this sporadic off-by-one-hour behavior also on > other Google services, most notably Search History and Blogger. > However the time error seen in those two services has been one hour > ahead instead of one hour behind as Kulvinder described. > -dave
Thanks for the information. If you have any more details on these problems with Search History and Blogger, please let me know and I'll get the information to the right people.
Meanwhile, we are working on solving this problem in Calendar.
> FWIW I've been seeing this sporadic off-by-one-hour behavior also on > other Google services, most notably Search History and Blogger. > However the time error seen in those two services has been one hour > ahead instead of one hour behind as Kulvinder described. > -dave
> On Feb 15, 3:16 pm, "Ryan Boyd (Google)" <api.rb...@google.com> wrote: > > Hi Kulvinder,
> > Thanks for the corroboration of the report.
> > Yes, we have tracked down the bug and are working on resolving it. > > Unfortunately, it's not as simple of a fix as it sounds, so I can't give > any > > timeline for resolution.
> > I'll post a note to the group when this is resolved.
> > Thanks again,
> > -Ryan
> > On 2/15/07, kulvinder_i...@yahoo.com <kulvinder_i...@yahoo.com> wrote:
> > > Hi Ryan,
> > > I also got this problem today morning. My Outlook and Google TimeZones > > > are both at GMT -5:00 EST. One of my Outlook Recurring event was at > > > 9:00 AM of duration 30 minutes. It was created in Google at 8:00 AM > > > instead. Other recurring events in the Outlook Calendar were at the > > > right time in Google.
> > > When i updated my Oultook event and pushed in Google again, the wrong > > > event was shifted to right time. I think the time shiftin of -1 hour > > > occurs only while adding the events in Google calendar.
> > > Any ideas ?
> > > On Feb 9, 6:55 pm, "Ryan Boyd (Google)" <api.rb...@google.com> wrote: > > > > Hi Charlie,
> > > > We are aware of and can reproduce the problem. We are working on > fixing > > > it, > > > > but unfortunately I can't give a timeframe.
> > > > Thanks for the reminder.
> > > > Cheers, > > > > -Ryan
> > > > On 2/8/07, Charlie Wood <charlie.w...@gmail.com> wrote:
> > > > > Ryan,
> > > > > I'm still seeing this behavior. Any news?
> > > > > Thanks, > > > > > Charlie
> > > > > On Jan 5, 10:51 am, "Ryan Boyd (Google)" <api.rb...@google.com> > wrote: > > > > > > Hi Derek,
> > > > > > We haen't found the exact cause yet, so I can only give you > guidance > > > > > > from my tests.
> > > > > > With the given syntax, for doing a recurring even that repeats > daily > > > > > > for an indefinite period of time and lasts 60 minutes, I am able > to> > > > reproduce this with at least 4 different hours with the12312006 > > > start > > > > > > date and using the US Central timezone (America/Chicago).
> > > > > > I was able to produce this on between 1 and 3 times out of 20 > > > requests > > > > > > in each batch run.
> > > > > > I'll post to the groups when I have more information about this > bug.
> > > > > > Cheers,
> > > > > > -Ryan
> > > > > > On Jan 4, 9:20 am, "Derek" <derek.tin...@timesearchinc.com> > wrote:
> > > > > > > Thanks Ryan and Charlie.
> > > > > > > I'd like to update our QA team to be aware of this issue, can > you > > > > > > > provide any guidance regarding what factors are involved in > the > > > > > > > manifestation of these recurrence issues?
> > > > > > > Any and all recurring events, specific TZ/times...
> > > > > > > Ryan Boyd (Google) wrote: > > > > > > > > I think I accidently hit 'Reply to author' on this one.
> > > > > > > > I have been able to successfully recreate this issue -- > thanks > > > to > > > > > > > > Charlie and all the information he provided.
> > > > > > > > While we will work to resolve this issue on our side, I did > > > notice > > > > > > > > during my testing that there is a way for the client to > check > > > > > whether > > > > > > > > the event was properly created. The gd:recurrence element > in > > > the > > > > > > > > response does include an incorrect value for those times > when > > > the > > > > > time > > > > > > > > for the event is offset.
> > > > > > > > For instance, after submitting the following: > > > > > > > > DTSTART;TZID=America/Chicago:20061231T080000 > > > > > > > > the following was returned: > > > > > > > > DTSTART;TZID=America/Chicago:20061231T070000
> > > > > > > > If you wish to handle this issue before the bug is resolved, > you > > > > > could > > > > > > > > look at the resulting gd:recurrence element and edit the > event > > > if > > > > > > > > necessary.
Maybe this has to do with the forthcoming timezone changes in March? The Mozilla Calendar team is working hard on just that issue, maybe you are having similar difficulties?
Philipp
On Feb 16, 7:40 pm, "Ryan Boyd (Google)" <api.rb...@google.com> wrote:
> Thanks for the information. If you have any more details on these problems > with Search History and Blogger, please let me know and I'll get the > information to the right people.
> Meanwhile, we are working on solving this problem in Calendar.
> Thanks,
> -Ryan
> On 2/16/07, dave <davekamin...@gmail.com> wrote:
> > FWIW I've been seeing this sporadic off-by-one-hour behavior also on > > other Google services, most notably Search History and Blogger. > > However the time error seen in those two services has been one hour > > ahead instead of one hour behind as Kulvinder described. > > -dave
> > On Feb 15, 3:16 pm, "Ryan Boyd (Google)" <api.rb...@google.com> wrote: > > > Hi Kulvinder,
> > > Thanks for the corroboration of the report.
> > > Yes, we have tracked down the bug and are working on resolving it. > > > Unfortunately, it's not as simple of a fix as it sounds, so I can't give > > any > > > timeline for resolution.
> > > I'll post a note to the group when this is resolved.
> > > Thanks again,
> > > -Ryan
> > > On 2/15/07, kulvinder_i...@yahoo.com <kulvinder_i...@yahoo.com> wrote:
> > > > Hi Ryan,
> > > > I also got this problem today morning. My Outlook and Google TimeZones > > > > are both at GMT -5:00 EST. One of my Outlook Recurring event was at > > > > 9:00 AM of duration 30 minutes. It was created in Google at 8:00 AM > > > > instead. Other recurring events in the Outlook Calendar were at the > > > > right time in Google.
> > > > When i updated my Oultook event and pushed in Google again, the wrong > > > > event was shifted to right time. I think the time shiftin of -1 hour > > > > occurs only while adding the events in Google calendar.
> > > > Any ideas ?
> > > > On Feb 9, 6:55 pm, "Ryan Boyd (Google)" <api.rb...@google.com> wrote: > > > > > Hi Charlie,
> > > > > We are aware of and can reproduce the problem. We are working on > > fixing > > > > it, > > > > > but unfortunately I can't give a timeframe.
> > > > > Thanks for the reminder.
> > > > > Cheers, > > > > > -Ryan
> > > > > On 2/8/07, Charlie Wood <charlie.w...@gmail.com> wrote:
> > > > > > Ryan,
> > > > > > I'm still seeing this behavior. Any news?
> > > > > > Thanks, > > > > > > Charlie
> > > > > > On Jan 5, 10:51 am, "Ryan Boyd (Google)" <api.rb...@google.com> > > wrote: > > > > > > > Hi Derek,
> > > > > > > We haen't found the exact cause yet, so I can only give you > > guidance > > > > > > > from my tests.
> > > > > > > With the given syntax, for doing a recurring even that repeats > > daily > > > > > > > for an indefinite period of time and lasts 60 minutes, I am able > > to> > > > reproduce this with at least 4 different hours with the12312006 > > > > start > > > > > > > date and using the US Central timezone (America/Chicago).
> > > > > > > I was able to produce this on between 1 and 3 times out of 20 > > > > requests > > > > > > > in each batch run.
> > > > > > > I'll post to the groups when I have more information about this > > bug.
> > > > > > > Cheers,
> > > > > > > -Ryan
> > > > > > > On Jan 4, 9:20 am, "Derek" <derek.tin...@timesearchinc.com> > > wrote:
> > > > > > > > Thanks Ryan and Charlie.
> > > > > > > > I'd like to update our QA team to be aware of this issue, can > > you > > > > > > > > provide any guidance regarding what factors are involved in > > the > > > > > > > > manifestation of these recurrence issues?
> > > > > > > > Any and all recurring events, specific TZ/times...
> > > > > > > > Ryan Boyd (Google) wrote: > > > > > > > > > I think I accidently hit 'Reply to author' on this one.
> > > > > > > > > I have been able to successfully recreate this issue -- > > thanks > > > > to > > > > > > > > > Charlie and all the information he provided.
> > > > > > > > > While we will work to resolve this issue on our side, I did > > > > notice > > > > > > > > > during my testing that there is a way for the client to > > check > > > > > > whether > > > > > > > > > the event was properly created. The gd:recurrence element > > in > > > > the > > > > > > > > > response does include an incorrect value for those times > > when > > > > the > > > > > > time > > > > > > > > > for the event is offset.
> > > > > > > > > For instance, after submitting the following: > > > > > > > > > DTSTART;TZID=America/Chicago:20061231T080000 > > > > > > > > > the following was returned: > > > > > > > > > DTSTART;TZID=America/Chicago:20061231T070000
> > > > > > > > > If you wish to handle this issue before the bug is resolved, > > you > > > > > > could > > > > > > > > > look at the resulting gd:recurrence element and edit the > > event > > > > if > > > > > > > > > necessary.
