Open vindzhev opened 8 months ago
Thanks for raising this @vindzhev
Out of curiosity, do you still get the same error if you change DateTimeOffset.UtcNow.AddMinutes(60)
to DateTimeOffset.Now.AddMinutes(60)
?
Yes, the issue still persists. The difference between using Now.AddMinutes and UtcNow.AddMinutes is what’s in the time zone portion of the serialized - +02:00/+00:00
The service should ideally accept both formats given that that they are valid dateTimeOffset
values according to the odata specification.
You can however pass a custom value as below. Any chance you confirm if it works out?
var subscription = new Subscription
{
ChangeType = "updated",
};
subscription.AdditionalData["expirationDateTime"] = DateTime.UtcNow.AddMinutes(60).ToString("o"); //DateTime objects get added a 'Z' not DateTimeOffset
Are you also able to share a sample of the response body (with the client-request-id
etc) when the error occurs when failing to create the subscription from Postman?
Appologize for the delayed asnwer. I will test the proposed option today and will get back to you as soon as possible. Thanks
Setting the expirationDateTime in the additional data worked as expected but not setting the the ExpirationDateTime of the Subscription object.
Describe the bug When using the client library (v5.36.0) and serializing the ExpirationDateTime property of Subscription class the result in value which is not accepted by the endpoint. The response error message indicates that expiration date is not provided at all: 400 expirationDateTime is a required property for subscription creation.
To Reproduce Steps to reproduce the behavior:
DateTimeOffset.UtcNow.AddMinutes(60)
)graphClient.Subscriptions.PostAsync(subscription)
methodExpected behavior New subscription is created succesfully.
Screenshots Using logger handler I can see the payload generated by the library:
Desktop (please complete the following information):
Additional context Leaving the ExpirationDateTime property unset (null) result into the same error message. Same request is issued using a postman - expectedly the same error occur. However, ammending the postman payload from
2023-12-28T18:23:45.9356913+00.00
to2023-12-28T18:23:45.9356913Z
is now accepted by the endpoint and processed as expected. Same behavior is observed when renewing subscription.