Looks like there is a bit of inconsistency between 2 ways calendar RECURRING events could be created using the TIME ZONE:
'quickAdd' - does not require you to provide a timezone. The Calendar's default (UTC) or the one set by the Calendar owner will be used. Fair enough.
'insert' - the API doc states: "For recurring events this field is required and specifies the time zone in which the recurrence is expanded. For single events this field is optional and indicates a custom time zone for the event start/end."
Why for 'insert'-ing recurring events we cannot use use the time zone the Calendar already have?
The 'quickAdd' api endpoint clearly shows that it is possible!
For example, if you call the quickAdd with the following text (Important meeting at Office at 11am-11:25am every Fri with John) recurring events will be created with the time zone that already set in the Calendar!
Sure thing that I could get the Calendar time zone from the settings (/calendar/v3/users/me/settings/timezone). But this will require one extra call. It will cause more latency and bring more complexity to the code.
Another issue. The quickAdd api call for recurring events creates not only recurring events but also the same event on the day when the call been made! The API doc does not provide any explanation what are the correct values for the text attribute.
Would be great to hear back from Google API team to clarify those things.
Thank you.
Related
I want to send email reminders to users and include the date and time in the email itself. How do I make sure that those are displayed in a user's current timezone, especially when the user might have traveled in the time he saved the record in the database?
Is the only way to just display the date in the email and include the timezone next to it?
Twilio SendGrid developer evangelist here.
When you send an email to a user, unless it is in response to a request that includes the user's current time zone, you cannot know for sure what time zone they are in. So, your suggestion to include the time zone in the date and time is a good idea.
One other suggestion is that you could send them an attachment with a calendar invite that includes the time of the event in UTC that can then be read and displayed by their calendar application in their own time zone.
When updating mailbox timezone in Exchange Online with Set-MailboxRegionalConfiguration, the timezone changes correctly but checking the mailbox through the OWA gui reveals that meeting hours have not changed to match, requiring a manual step by the user.
Message reads:
The current zone for your meeting hours is [timezone]
and is asking if the user is going to remain in the new timezone and to change the meeting hours to match.
Is it possible to set the meeting hours via Powershell?
If anyone comes across this, we ended up using the Graph API to amend this
Paypal documentation for PayPal Sync API (https://developer.paypal.com/docs/api/sync/v1/).
It gives some mysterious date, named "last_refreshed_datetime".
On the sandbox server it is usually in the past, once it was a few days in the past, now it is 2 hours in the past.
What does it mean? How often it refreshes?
I only know that if I create a transaction it will not be visible on PayPal Sync API until the refresh date will not be later than the transaction date. And I'm guessing it should be the transaction approval date that does not presented on this report. The transaction approval date is available on transaction object (https://developer.paypal.com/docs/api/subscriptions/v1/#definition-transaction), it is called "time".
time string
The date and time when the transaction was processed, in Internet date and time format.
Read only.
I have reached out to the product development team for the SYNC API and have gotten the following clarifications in regards to your questions:
If the "last_refreshed_datetime" (Time until which we have data available in our system) is smaller than the requested end date then, in the API response we show end date as "last_refreshed_datetime". As we only have data up until that point. In general there should be around 4-6hrs of delay.
From my own experience on sandbox, on different occasions it was 6.5, 2.5 hours and even 2 days behind.
Assuming I have a news app and I am in the year of 2018:
If the user says something like "Give me June's news", DialogFlow will resolve it to June 2019. I understand that it makes sense for some applications like event scheduling, but for my app, how can I control (train) it to resolve to the current calendar year?
You could customize your response in a fulfillment webhook. For example, you could set up a fulfillment function that will read the value of the date system entity and perform appropriate logic.
Depending on whether you're using Actions on Google client library or Dialogflow fulfillment library, the syntax will be different. Please refer to the docs for Actions on Google or Dialogflow on how to extract the values of entities from DialogFlow.
You shouldn't need to train DialogFlow with what the current year is, your webhook service (logic) should make this assumption.
Please suggest the following:
when a user want a certain package in my site, let's call it basic package.. his starting his recurring payment..after half a month he canceles the package, but his still paid for a full month, my question is this:
When recurring payment involved, what kind of fields should i save from the ipn, and how should i know exactly when to stop the features of the package a user bought...
I've seen in the ipn, i have 'next recurring payment' date, should i save it and use it? should i, every time a user do anything related to his package,check if the package limit time just ended?
What can be a most preferred solution for this?
When recurring payment involved, what kind of fields should i save from the ipn
All of them, for any kind of IPN whatsoever. Log the entire transaction every time.
and how should i know exactly when to stop the features of the package a user bought...
You should definitely stop when you get a cancel or eot IPN message. You probably don't want to deny service just because of payment difficulties. See below for the rest of it.
I've seen in the ipn, i have 'next recurring payment' date, should i save it and use it?
Save everything. Then you don't have a problem.
should i, every time a user do anything related to his package, check if the package limit time just ended? What can be a most preferred solution for this?
I have a 'subscriptions' table which shows the user/product pair and the expiry date. Every time he pays the expiry date is pushed out another period, or maybe I create it with the final expiry date, I don't remember offhand. When he logs in, he is given the roles associated with all his subscriptions that haven't expired yet.
If he tries to do something he can no longer do due to an expiry:
he isn't even provided with a link in the first place by the webapp, so he can't get there by any direct action
in any other case, e.g. somewhere I forgot to do that, or when he tries to access via a bookmark, container-managed authentication will see that he isn't in the appropriate role and give him a 403.
He can also see a table of his subscriptions showing how long they have left to run, and another table of expired subscriptions.