Exchange Online: Changing timezone for meeting hours? - powershell

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

Related

Email reminders - correct timezone

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.

Paypal Sync Api last_refreshed_datetime - what does it mean, how often it refreshes?

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.

Google Calendar API V3 insert recurring event default timezone

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.

Active Directory Login Report

To make a long story short, we have some staff punctuality issues where we'd like to setup some type of report / monitor that would send supervisors login time stamps during morning hours mostly. I don't know if this is possible through event logs or what not by scripting some type of report, however at this point I'm looking for solutions. Any suggestions?
LastlogonTimestamp is not synced in anything near real time. so that will not work for daily reporting.
i would collect the security logon events with the relevant Event ID's and work from there with the reporting.
an alternative is to scavenge the LastLogon property from user objects. But that is non-replicated attribute so you would need to read that for a user from all DC's or where it exists.

Convert UTC date to user's timezone in email message

I'm building a site that stores date/time values in UTC on the database.
When I display these values, I use javascript to convert them to the current's user timezone. This is working correctly so far.
Now I want to send some information to users by email (something like a reminder), and this should have the date time as well.
I don't want to print the UTC time in the email, and since I'm sending the email from the server I don't have access to the user's current timezone.
What's the best approach to solve this? should I store the timezone of the user whenever he logs in and use that to convert the date?
Any comments are appreciated.
Yes, you can detect the user's timezone using Javascript, have the Javascript submit that information to the server, and have the server store it as a preference. If the user sometimes changes timezones you could even keep track of which one they are in most frequently and use that one.