Google Calendar API events list time zone issue - timezone

Since mid of last week I witnessed increasing issues with the events list query params for upper and lower bounds. Since the weekend it is no longer working at all.
Issue summary:
Positive timezone offsets no longer accepted in events list query params for time bounds.
Api call:
GET https://www.googleapis.com/calendar/v3/calendars/<myCalendarId>/events
with query params: ?timeMin=2020-12-01T09:31:04+0100
Expected behavior and behavior until around Nov 25th, on some servers until Nov 27th:
{
"kind": "calendar#events",
"etag": "\"blahblah\"",
"summary": "blahblah",
"updated": "2020-12-01T07:46:56.357Z",
"timeZone": "Europe/Berlin",
"accessRole": "owner",
"defaultReminders": [
{
"method": "popup",
"minutes": 30
}
],
"nextSyncToken": "blahblah",
"items": [
...
Actual behavior / response body:
{
"error": {
"errors": [
{
"domain": "global",
"reason": "badRequest",
"message": "Bad Request"
}
],
"code": 400,
"message": "Bad Request"
}
}
Further details:
Apparently the "bad request" response is solely induced by the plus (+) symbol before the time zone offset. Changing the "+" to a "-" in the above request will return a valid response as expected only that the offset is wrong (in this case by two hours as it should be).
Writing the offset with or without ":" (e.g. +01:00 vs +0100) does not affect results.
Most likely I have missed something like a depreciation of positive time zone offsets or I was anyway using a wrong time format since I am admittedly not an expert in the RFC3339.
The other option is that the Google calendar team has updated their parser in their calendar API and in the wake of that deployed a bug. In that case a test case should be added to the pipeline for testing several time zone offsets including the limits.
I would be happy to receive advice on how to gracefully select and time zone east of UTC.
Thanks a lot in advance!

There is no such deprecation, but when you make an HTTP request you need to URL encode the parameters
Sample:
https://www.googleapis.com/calendar/v3/calendars/primary/events?q=timeMin%3D2020-12-01T09%3A31%3A04%2B0100

Related

Microsoft Graph API - unterminated string literal Error when searching for emails which contain # in the subject

When i am searching for emails on office 365 in a batch query, i am getting a unterminated string literal error. This is happening only when i have a # character in the subject search query.
Forum discussions like this (https://issues.oasis-open.org/browse/ODATA-1101) have suggested me to percentage encode the # symbol but it gave the same error.
When I am POSTing the below request to the batch endpoint(https://graph.microsoft.com/v1.0/$batch)
{
"requests": [{
"id": 1,
"method": "GET",
"url": "/users/somemailbox#mytenant.onmicrosoft.com/messages?$select=id,internetMessageId,toRecipients,ccRecipients,bccRecipients,subject,isRead,sender,receivedDateTime&$top=500&$search=\"received>=2019-06-19 AND (subject:\\\"PO# 123\\\" AND from:email#domain.com)\""
}]
}
I get this error
{
"responses": [
{
"id": "1",
"status": 400,
"body": {
"error": {
"code": "BadRequest",
"message": "There is an unterminated string literal at position 39 in '\"received>=2019-06-19 AND (subject:\\\"PO'.",
"innerError": {
"request-id": "801078a5-d3c6-4b93-a152-6653a3d8ca44",
"date": "2019-07-22T06:29:16"
}
}
}
}
]
}
Can you guys please help me with fixing my search query?
Thanks,
Ashish
The # character is used to delimit fragments in a URL, which are intended to represent client side state. Browsers will generally not send the # or anything following it, and servers will generally ignore it if it's sent accidently.
Your issue is most likely an encoding one - depending on how you're encoding the query string the # might be getting left alone, when in actuality you want it to be encoded to %23.

Using filter on /me/joinedTeams not working

I'm implementing a search for a user's joined Teams unsing Microsoft Graph. The idea is to make a call to /beta/me/joinedTeams and use a ?$filter=startswith(description,'searchterm') filter.
So for example when I try the request https://graph.microsoft.com/beta/me/joinedTeams?$filter=startswith(description,'Business') in the Microsoft Graph Explorer it ignores the filter and I get these results:
{
"#odata.context": "https://graph.microsoft.com/beta/$metadata#groups",
"value": [
{
"id": "02bd9fd6-8f93-4758-87c3-1fb73740a315",
"displayName": "HR Taskforce",
"description": "Welcome to the HR Taskforce team.",
"isArchived": false
},
{
"id": "13be6971-79db-4f33-9d41-b25589ca25af",
"displayName": "Business Development",
"description": "Welcome to the BizDev team.",
"isArchived": false
},
{
"id": "8090c93e-ba7c-433e-9f39-08c7ba07c0b3",
"displayName": "X1050 Launch Team",
"description": "Welcome to the team that we've assembled to launch our product.",
"isArchived": false
}
]
}
Am I doing something wrong with my request?
Your request is right, but the joinedTeams does not support filtering or ordering results. So although we pass the filter/orderby parameter, when Microsoft Graph sees a query parameter it doesn't expect, it simply ignores the unknown filter/orderby parameter and returns an unfiltered/default-sorted result.
I have tried the api with odata query parameters for trial O365 account and real account.
https://developer.microsoft.com/en-us/graph/docs/concepts/query_parameters
Not all parameters are supported across all Microsoft Graph APIs, and
support might differ significantly between the v1.0 and beta
endpoints.
The only suggestion for you is to vote up the existing feature request in User Voice or submit a new one.
Thanks for pointing this out. As Seiya points out, /me/joinedTeams does not support the OData query parameters. The documentation suggested otherwise, I've made a doc fix that should propagate in the next day or two.

Google Sheets API v4 Spreadsheets.Values.Append returns ERROR 500 and 503

Google Sheets API v4
This API has been giving error 500 and error 503 for 24+ hours.
The code was working previously for many months and nothing has changed.
I know 500 and 503 are supposed to be internal errors, but from searches it seems that they are returned in obscure cases that might not be well documented that users can work around.
The issues is not related to rate-limiting. My gut feel was related to an auth token expiring (as nothing in the code had changed), but I tried refreshing the auth token and still get the issue.
I don't see any issues on Google's status/uptime pages.
The response from the sheets.spreadsheets.values.append API is usually:
{
"code": 503,
"errors": [
{
"message": "The service is currently unavailable.",
"domain": "global",
"reason": "backendError"
}
]
}
But sometimes also:
{
"code": 500,
"errors": [
{
"message": "Internal error encountered.",
"domain": "global",
"reason": "backendError"
}
]
}
Example request payload, which includes an actual sheet ID that repros this if there's a Googler available to try it repro on their end:
{
"spreadsheetId": "1_P5IR4OLbYd27L9m184R37L_PP2drCk6PSJndIlEhms",
"range": "Incoming!A4",
"valueInputOption": "USER_ENTERED",
"insertDataOption": "INSERT_ROWS",
"resource": {
"values": [
[
"=HYPERLINK(\"https://url/\", \"Blah\")",
"6/13 22:18",
"=IF(AND(INDIRECT(\"R[0]C[3]\",false)<>\"\",INDIRECT(\"R[0]C[9]\",false)=\"\"),((INDIRECT(\"R[0]C[-1]\",false)+C$3/24)-NOW())*24,)",
"dv1",
"testdoc",
"170613_006_0400PM.MP3",
"00:40:00.000",
"",
"",
"",
"",
"",
"=IF(INDIRECT(\"R[0]C[-1]\",false)<>\"\",IFERROR(INDIRECT(\"R[0]C[-6]\",false)/INDIRECT(\"R[0]C[-1]\",false),\"---\"),)",
"",
"",
"",
"",
"",
"=IF(INDIRECT(\"R[0]C[1]\",false)=\"\",(INDIRECT(\"R[0]C[-17]\",false)+S$3/24-NOW())*24,)",
""
]
]
},
"auth": {
"transporter": {},
"clientId_": "anonymizied.apps.googleusercontent.com",
"clientSecret_": "anonymizied",
"redirectUri_": "urn:ietf:wg:oauth:2.0:oob",
"opts": {},
"credentials": {
"access_token": "anonymizied",
"refresh_token": "anonymizied",
"token_type": "Bearer",
"expiry_date": 1502144766732
}
}
}
I've carefully worked out this issue and a workaround. It's definitely a bug on Google's side, which seems to have been pushed to production around Aug 5th (+/- 1.5 days).
In my case, simply un-hiding a hidden row resolves the error. Hiding the row again reproduces the issue.
So if you hit this error, try un-hiding any hidden rows.
I have filed this issue with Google at https://issuetracker.google.com/64468867, but it seems they only triage public issues there every month or two.
This was an issue on the Google Sheets side, sorry. The fix is now rolled out so the problem shouldn't happen anymore. Please reply back here if it continues.

504 Gateway Timeout (UnknownError) when trying to track changes in a user's calendar

For our internal application we synchronize our user's calendars (in our Office 365 tenant) with a local "cache" in our database. We're using the new Delta Queries in Microsoft Graph to do track these changes.
Most of the calendars synchronize correctly, but for some reason there is one single calendar where we consistently hit a 504 Gateway Timeout error when attempting to request the events using the nextLink received from the first request.
First request:
GET https://graph.microsoft.com/v1.0/users/<userId>/calendars/<calendarId>/calendarView/delta?startDateTime=2017-06-10t00%3A00%3A00Z&endDateTime=2018-06-10t00%3A00%3A00Z
First response:
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#Collection(event)",
"#odata.nextLink": "https://graph.microsoft.com/v1.0/users/<userId>/calendars/<calendarId>/calendarView/delta?$skiptoken=R0usmcdvmMuZCBYV0hguCGmIJqcU0n_6jVFWUlNKbXkBKYVlxLSMsISZI5sLLLJyLJF8hZIj0PURpAeP_XxydW_qbMUoFMTXjOpLa8Ta6rxMRA7Wv6IHYfjyLPcDzCbM_hKvTgq8BZaBeJv-a61mebF6X2wT4HqCAGL5lL4nLZabHk1nD9GbWJ0a4Qq0M41_GPYxEi5YNe9u1673SQ1Djw.F85xXB6GjtO7myCQCOgFvzp1G7mQB0BvuHQJyn0CICQ",
"value": [
<list of events>
]
}
Second request:
GET https://graph.microsoft.com/v1.0/users/<userId>/calendars/<calendarId>/calendarView/delta?$skiptoken=R0usmcdvmMuZCBYV0hguCGmIJqcU0n_6jVFWUlNKbXkBKYVlxLSMsISZI5sLLLJyLJF8hZIj0PURpAeP_XxydW_qbMUoFMTXjOpLa8Ta6rxMRA7Wv6IHYfjyLPcDzCbM_hKvTgq8BZaBeJv-a61mebF6X2wT4HqCAGL5lL4nLZabHk1nD9GbWJ0a4Qq0M41_GPYxEi5YNe9u1673SQ1Djw.F85xXB6GjtO7myCQCOgFvzp1G7mQB0BvuHQJyn0CICQ
Second response:
504 Gateway Timeout
{
"error": {
"code": "UnknownError",
"message": "",
"innerError": {
"request-id": "0784cffb-cba7-424b-be1d-74b2bfef5da1",
"date": "2017-07-10T09:11:33"
}
}
}
I've tried executing the script a few times over the last week, but the request consistently fails when using requesting the second page. Other calendars synchronize with no issues, so I don't really know how to debug these kind of issues. Is there anything we can do to resolve this issue?
I'm working with the team that owns Calendar sync to check where the latency in the stack is causing this time out. I'll post as soon as they have root caused this. I may need more info on what is special about this one Calendar encountering this issue.
Thanks,
Sri

Facebook graph API: Event timezone, time

I am currently having a problem with getting the correct time for an event via Facebook's graph API. There are some events showing the correct time and some are not. Even if I am calculating the timezone wrongly, it just doesn't make sense to me.
For example I have the following three events: "Brunch", "Champions league finale" and "Pfingst-Tanz". That's what the graph API gives back:
{
"data": [
{
"name": "Pfingst-Tanz",
"start_time": "2012-05-27T10:00:00",
"end_time": "2012-05-27T14:00:00",
"timezone": "Europe/Berlin",
"location": "...",
"id": "..."
},
{
"name": "Championsleague Finale",
"start_time": "2012-05-19T11:45:00",
"end_time": "2012-05-19T14:45:00",
"timezone": "Europe/Berlin",
"location": "...",
"id": "..."
},
{
"name": "Muttertagsbrunch",
"start_time": "2012-05-13T10:00:00",
"end_time": "2012-05-13T14:00:00",
"location": "...",
"id": "..."
}
],
"paging": { … }
}
On the Facebook page it shows:
Pfingst-Tanz 19:00 (07:00 pm)
Champions league finale 20:45 (8:45 pm)
Brunch 10:00 (10:00 am)
Which results in:
Pfingst-Tanz: Facebook page correct, API incorrect or TZ incorrect in my app
(Champions league finale: don't know, never mind)
Brunch: Facebook page and API correct and same
This just does not correspond to each other. From what I understand it has to be either all wrong or none wrong, but not just 1/3 or 2/3 events. Does anyone have an idea, or am I just too blind to see something?
Your "Brunch" event doesn't include a time zone, so it can't be adjusted to the user's local time zone, which is what I assume Facebook is doing.
It's not immediately clear to me whether the start_time and end_time values are meant to represent the local start/end times (in the given time zone) or the UTC start/end times, but that should be easy enough to work out based on the data (and documentation, hopefully). I suspect it's the UTC start/end when there's a time zone specified, but the local start/end otherwise.

Resources