J'utilise actuellement l'API Office Graph pour gérer les réunions des utilisateurs Calendriers. Je me suis abonné pour recevoir des notifications si un événement est créé, mis à jour et supprimé à l'aide de la requête "/ subscriptions"! Mes utilisateurs utilisent le fuseau horaire de Lisbonne (en été = UTC + 1, en hiver = UTC)
Lorsqu'un événement est créé dans Office 365 par un utilisateur, du côté de mon application, si l'événement est une réunion récursive sans date de fin je mets à jour (via l'API Graph) la réunion pour qu'elle ait une date de fin . [Remarque: l'une des règles de ma candidature est qu'aucune réunion ne dure plus de 365 jours.]
Problème: la série est réduite à la date de fin que j'ai mise à jour via l'API, mais l'heure est laissée avec le mauvais fuseau horaire. J'ai déjà essayé de demander l'API sans fuseau horaire et j'ai déjà demandé une mise à jour avec le fuseau horaire UTC et le fuseau horaire UTC +1 et j'ai toujours le même problème. Côté bureau, après ma mise à jour, l'heure de la réunion est d'une heure en moins.
L'image suivante est un exemple de série, qui n'a pas de plage de fin:
Je récupère quelques réunions d'enfants avant la mise à jour et c'est correct. Au Portugal, le jour du changement d'heure est le 2019-03-30, donc le jour 30 commence à 10h00 UTC et le jour 31 09:00 UTC:
Ici, j'envoie la demande à Office 365 pour mettre à jour la fin de la récurrence (date de fin):
Après avoir envoyé la demande de mise à jour, je récupère les mêmes enfants et le 30/03/2019 et le 31/03/2019 commencent tous les deux à 10h00. Après cette mise à jour dans l'agenda client, les réunions ont des heures de début et de fin incorrectes:
J'ai déjà essayé de mettre dans le domaine de l'API Graph recurrenctTImeZone: UTC, GMT Standard Time et simplement ne rien mettre et j'ai toujours le même retour. Je ne peux pas résoudre ce problème.
Avez-vous une idée de ce qui pourrait ne pas aller?
3 Réponses :
Vous pouvez effectivement l'utiliser dans l'en-tête des requêtes
Prefer: outlook.timezone="Central Standard Time"
De cette façon, il sait dans quel fuseau horaire vous voulez travailler avec vos calculs. Une documentation supplémentaire à ce sujet est disponible ici https://docs.microsoft.com/en-us/graph/api/user-list-events?view=graph-rest-1.0#support-various-time-zones a>
Nous vous avons déjà envoyé quoi suggérer dans l'en-tête GET and UPDATE et cela n'a pas fonctionné. Le problème est exactement le même.
Je ne reproduis pas ce comportement avec un utilisateur dans le fuseau horaire Pacific Standard Time OU le fuseau horaire GMT Standard Time. Pour plus de clarté, je fais tous les tests avec Postman, et je n'ai pas utilisé l'en-tête Prefer: outlook.timezone que Jeremy a souligné ci-dessus.
J'ai créé un rendez-vous quotidien sans fin pour l'utilisateur à 14 heures du Pacifique, soit 22 heures UTC. Notez également que l'heure d'été commence dans ce fuseau horaire le 10 mars. Comme vous pouvez le voir ci-dessous, les heures sont correctes sur les instances avant et après la mise à jour.
J'ai également répété cette même séquence d'événements pour un utilisateur dans le fuseau horaire GMT Standard (configuré comme ceci dans Outlook sur le Web):
J'ai obtenu exactement les mêmes résultats pour cet utilisateur.
Je suggère que lorsque vous corrigez la récurrence, vous utilisez toujours la recurrenceTimeZone de la récurrence d'origine. Vous avez peut-être corrompu la récurrence en appliquant un correctif avec UTC à l'origine.
Obtenir l'événement après la création dans Outlook sur le Web
{
"value": [
{
"id": "AAMkAGE1NWM...",
"originalStartTimeZone": "Pacific Standard Time",
"originalEndTimeZone": "Pacific Standard Time",
"start": {
"dateTime": "2019-03-09T22:00:00.0000000",
"timeZone": "UTC"
},
"end": {
"dateTime": "2019-03-09T22:30:00.0000000",
"timeZone": "UTC"
}
},
{
"@odata.etag": "W/\"bReRxUIs3kGIyXXcVJg69AAANf7nZQ==\"",
"id": "AAMkAGE1NWM...",
"originalStartTimeZone": "Pacific Standard Time",
"originalEndTimeZone": "Pacific Standard Time",
"start": {
"dateTime": "2019-03-10T21:00:00.0000000",
"timeZone": "UTC"
},
"end": {
"dateTime": "2019-03-10T21:30:00.0000000",
"timeZone": "UTC"
}
}
]
}
GET /me/events/{id}/instances?startDateTime=2019-03-09T00:00:00&endDateTime=2019-03-11T00:00:00&
$select=originalStartTimeZone,originalEndTimeZone,start,end
Récupérer les instances avant de modifier
Notez le décalage des heures de début / fin.
PATCH /me/events/{id}
{
"recurrence": {
"pattern": {
"type": "daily",
"interval": 1,
"month": 0,
"dayOfMonth": 0,
"firstDayOfWeek": "sunday",
"index": "first"
},
"range": {
"type": "endDate",
"startDate": "2019-01-24",
"endDate": "2020-01-23",
"recurrenceTimeZone": "Pacific Standard Time",
"numberOfOccurrences": 0
}
}
}
{
"value": [
{
"id": "AAMkAGE1NWM...",
"originalStartTimeZone": "Pacific Standard Time",
"originalEndTimeZone": "Pacific Standard Time",
"start": {
"dateTime": "2019-03-09T22:00:00.0000000",
"timeZone": "UTC"
},
"end": {
"dateTime": "2019-03-09T22:30:00.0000000",
"timeZone": "UTC"
}
},
{
"@odata.etag": "W/\"bReRxUIs3kGIyXXcVJg69AAANf7nZQ==\"",
"id": "AAMkAGE1NWM...",
"originalStartTimeZone": "Pacific Standard Time",
"originalEndTimeZone": "Pacific Standard Time",
"start": {
"dateTime": "2019-03-10T21:00:00.0000000",
"timeZone": "UTC"
},
"end": {
"dateTime": "2019-03-10T21:30:00.0000000",
"timeZone": "UTC"
}
}
]
}
Mettre à jour la récurrence de l'événement pour ajouter une date de fin
Notez que j'ai laissé recurrenceTimeZone comme même valeur que l'original.
GET /me/events/{id}/instances?startDateTime=2019-03-09T00:00:00&endDateTime=2019-03-11T00:00:00&
$select=originalStartTimeZone,originalEndTimeZone,start,end
Récupérer les instances après modification
Notez que les heures de début / fin sont toujours décalées correctement .
{
"id": "AAMkAGE1NWM...",
"originalStartTimeZone": "Pacific Standard Time",
"originalEndTimeZone": "Pacific Standard Time",
"start": {
"dateTime": "2019-01-24T22:00:00.0000000",
"timeZone": "UTC"
},
"end": {
"dateTime": "2019-01-24T22:30:00.0000000",
"timeZone": "UTC"
},
"recurrence": {
"pattern": {
"type": "daily",
"interval": 1,
"month": 0,
"dayOfMonth": 0,
"firstDayOfWeek": "sunday",
"index": "first"
},
"range": {
"type": "noEnd",
"startDate": "2019-01-24",
"endDate": "0001-01-01",
"recurrenceTimeZone": "Pacific Standard Time",
"numberOfOccurrences": 0
}
}
}
GET /me/events/{id}&$select=originalStartTimeZone,originalEndTimeZone,start,end,recurrence
Après plusieurs tentatives de résolution, j'ai pu parler à l'équipe de développement Office 365 et j'ai été surpris par les commentaires négatifs.
Ils ont indiqué qu'en fait il existe un bogue inconnu dans l'API Graph de Microsoft dans cette situation spécifique et qu'ils ne garantissent pas la résolution de ce bogue!
Leur suggestion est que nous utilisions le API du calendrier Outlook Rest API uniquement pour cette situation. En conclusion, à cause de cette erreur inconnue déjà assumée par Microsoft, je devrai implémenter 2 API différentes dans ma plateforme: l'API Microsoft Graph qui est actuellement recommandée par Microsoft, et l'API Outlook Calendar Rest à cause de ce bogue.
Solution de repos de l'API du calendrier Outlook:
Envoyez-vous d'autres valeurs dans votre requête PATCH (en plus de
récurrence)?Jason, non, je viens d'envoyer ce qui est dans l'image ci-dessus représentant la demande de ma mise à jour de fin de récurrence.