1

I have this python code below to create a meeting event, and it is working. I plan to incorporate this script with the Web Form submision where user enters some basic information such as Subject, attendees, and meeting date/time, and then the Python script will create a meeting event based on submitted info from the web form. That I have no problem to accomplish, but the problem is the timezone of the meeting.

As you can see the Python script requires Start/End time as this ""2016-08-03T15:00:00-07:00" (the -07:00 is for PDT time). However, the web form does not know what timezone of current user (users could be in West, Mountain, Central, or East timezone). It is too complicate to figure out the timezone is -7(PDT), -8(PST), -6(CT)....

Is there a way to query the current time zone setting of the person who creates the meeting based on user login? Then convert that timezone to number (-7 for PDT, -8 for PST, -6 CT...)... so the "StartTimeZone" and "EndTimeZone" have the correct time?

# Set the request parameters
url = 'https://outlook.office365.com/api/v1.0/me/events?$Select=Start,End'
user = 'user1@domain.com'

pwd = getpass.getpass('Please enter your AD password: ')


# Create JSON payload
data = {
  "Subject": "Testing Outlock Event",
  "Body": {
    "ContentType": "HTML",
    "Content": "Test Content"
  },
  "Start": "2016-08-03T15:00:00-07:00",
  "StartTimeZone": "Pacific Standard Time",
  "End": "2016-08-03T16:00:00-07:00",
  "EndTimeZone": "Pacific Standard Time",
      "Attendees": [
    {

      "EmailAddress": {
        "Address": "attendee1@domain.com",
        "Name": "User2"
      },
       "Type": "Required"  },

       {
      "EmailAddress": {
        "Address": "attendee2@domain.com",
        "Name": "User3"
      },
       "Type": "Optional"  }
  ]
}

json_payload = json.dumps(data)

# Build the HTTP request
opener = urllib2.build_opener(urllib2.HTTPHandler)
request = urllib2.Request(url, data=json_payload)
auth = base64.encodestring('%s:%s' % (user, pwd)).replace('\n', '')
request.add_header('Authorization', 'Basic %s' % auth)
request.add_header('Content-Type', 'application/json')
request.add_header('Accept', 'application/json')
request.get_method = lambda: 'POST'
# Perform the request
result = opener.open(request)
Milacay
  • 1,407
  • 7
  • 32
  • 56

1 Answers1

1

You can get user's timezone offset from UTC with JavaScript on the client and then pass this value to the server during form submission. See this answer.

UPDATE:

Assuming your user's locale is set up correctly, getTimezoneOffset() will return timezone offset from UTC, in minutes, for the current locale (source). You don't have to worry about daylight saving time. Use UTC time as the base for conversion. When you get the offset, convert the meeting time specified by the user to UTC using this offset, then convert UTC time to the timezone used on the server.

UPDATE 2:

I realized that in fact you should care about daylight saving time, because getTimezoneOffset() returns the current offset while the user can create an event somewhere in the future, after the daylight saving time will change this offset and the conversion will become inaccurate. So the right solution is not to use the current UTC offset directly, but use it instead to get the real timezone that you will then use for conversion. jsTimezoneDetect library can do this for you.

Community
  • 1
  • 1
wombatonfire
  • 4,585
  • 28
  • 36
  • Thanks for the advice. I will try that as last resort. Do you know that Javascript function would also distinguish when the Day Light Saving and Non-Day Light Saving time changes? Example, Pacific Time changes from -7 to -8 and vice verse. – Milacay Aug 02 '16 at 21:00
  • Updated the answer. I don't think you could find any other option to determine client's time programmatically. The only other option is to allow the user to specify the timezone himself. – wombatonfire Aug 02 '16 at 21:48
  • Thank you. I will try that. – Milacay Aug 02 '16 at 22:00
  • I must admit, I was too optimistic about the daylight saving time. It should be taken into account. Please see update 2. – wombatonfire Aug 02 '16 at 23:02