3
votes

I got in trouble with creation of an all day event appointment using Exchange 2010 Web Services (EWS) .

According to existing requirements to create an All day event appointment object needs to have specified start and end time (i.e. 10/20/2011 12:00:00 AM), and also timezone.

But my application converted to use EWS instead of WebDAV sets start and end time converted to GMT (Greenwich) time which then sent to Exchange server.

Such technique worked perfectly with WebDAV. But with EWS I get weird result: appointment spans on 3 (three) days, and is NOT All day event appointment !!!

My mailbox timezone set to Pacific Standard Time (using OWA interface), and Exchange server Date and Time also set to Pacific Standard time.

Appointment start and end times are set to “2011-10-20T07:00:00.000Z” and “2011-10-21T07:00:00.000Z” respectively. In terms of local time these times are “10/20/2011 12:00:00 AM” and “10/21/2011 12:00:00 AM” respectively (considering Daylight Saving time).

If IsAllDayEvent property of appointment object set to False – appointment created correctly – not as All day, starts at 10/20/2011 12AM and ends at 10/21/2011 12AM, and occupies only one day – October /20/2011 in Outlook Calendar.

But If isAllDayEvent property of appointment object set to True (everything rest remains the same) – appointment starts at Oct/19/2011 9:00:00PM, ends at Oct/21/2011 9:00:00PM, and is NOT All day.

It might be that I’m doing something wrong, but based on described above following question raised for me:

  • does EWS support Greenwich Time for All day events?
    If yes – what might be my mistakes?

I appreciate any suggestion. Sincerely Andrew

4

4 Answers

4
votes

Ran into a similar problem where my all day event was being created from 4pm the previous day to 4pm the specified date of the all day event (I'm currently in pacific standard time -8 so appears to be a UTC bug on the exchange server side).

When calling Appointment.save, use the optional second parameter, SendInvitationsMode.SendToNone, e.g.:

a.save(new FolderId(WellKnownFolderName.Calendar), 
    SendInvitationsMode.SendToNone);

If you prefer XML see Envelope/Body/CreateItem/@SendMeetingInvitations:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages"
    xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">
    <soap:Header>
        <t:RequestServerVersion Version="Exchange2007"></t:RequestServerVersion>
    </soap:Header>
    <soap:Body>
        <m:CreateItem SendMeetingInvitations="SendToNone">
            <m:SavedItemFolderId>
                <t:DistinguishedFolderId Id="calendar"></t:DistinguishedFolderId>
            </m:SavedItemFolderId>
            <m:Items>
                <t:CalendarItem>
                    <t:Subject>From Java EWS</t:Subject>
                    <t:Body BodyType="HTML">the body</t:Body>
                    <t:Start>2014-01-03T00:00:00Z</t:Start>
                    <t:End>2014-01-04T00:00:00Z</t:End>
                    <t:IsAllDayEvent>true</t:IsAllDayEvent>
                </t:CalendarItem>
            </m:Items>
        </m:CreateItem>
    </soap:Body>
</soap:Envelope>
0
votes

In addition to Pete's answer:
Note that there is a difference between what Exchange has stored and what Outlook tells you. I'm writing 'pure' SOAP XML calls to an Exchange 2010 Server calendar and viewing the results through Outlook 2003. The creation calls explicitly specify UTC times and have no other time zone information. The server has UTC settings.
If I now create an allday event like this:

  <mes:CreateItem SendMeetingInvitations="SendToNone">
  <mes:Items>
     <typ:CalendarItem>
       <typ:Subject>Alldayevent</typ:Subject>
       <typ:Start>2013-01-08T01:00:00.000Z</typ:Start>
       <typ:End>2013-01-08T02:00:00.000Z</typ:End>
       <typ:IsAllDayEvent>true</typ:IsAllDayEvent>

... Exchange correctly stores this as (GetItem output):

<t:Start>2013-01-08T00:00:00Z</t:Start>
<t:End>2013-01-09T00:00:00Z</t:End>
<t:IsAllDayEvent>true</t:IsAllDayEvent>

If Outlook is also configured for UTC this shows as an all day event for 8. January (as expected).

However, if I set Outlook to UTC+1 (Amsterdam time), the event is displayed extending over two days (and note he checkbox being blank): Not exacty an all-day event

Checking 'All day' in that situation results in (GetItem output):

 <t:Start>2013-01-07T23:00:00Z</t:Start>
 <t:End>2013-01-09T23:00:00Z</t:End>
 <t:IsAllDayEvent>true</t:IsAllDayEvent>
0
votes

I'm doing a DAV to EWS conversion myself. Something that might be of interest I ran across from Best Practices for Using Exchange Web Services for Calendaring Tasks (Ex 2007, but I assume applies to Exchange 2010 and 2013)

When Exchange Web Services receives a request to create a new CalendarItem for which the start and End properties are identified by non-UTC-offset strings, the server must convert the Start and End properties to Coordinated Universal Time (UTC) before the CalendarItem can be stored. The following are the rules for the conversion to UTC:

If the request contains an explicit time zone definition via a MeetingTimeZone property, the server will apply the correct offset with regard to Standard and Daylight rules as defined by the time zone.

If no explicit time zone is defined, the current time zone of the computer that is running Exchange 2007 (specifically, the Client Access server that is processing the request) will be used.

Note: In Exchange 2007 SP1, all unspecified time zones are set to UTC instead of the time zone of the Client Access server.

Experimenting a little bit, I found that if you do not specify a timezone, EWS will indeed apply the time as UTC. If IsAllDayEvent is true start times and end are ignored besides their date component. So an all day event turns into 12:00am-12:00am UTC or 5:00pm-5:00pm on my calendar (I'm -7 UTC also). The Best Practices article recommends using the MeetingTimeZone element, but I received an error that it was depreciated, use StartTimeZone and EndTimeZone instead. Indeed adding <StartTimeZone Id="Pacific Standard Time"> seems to work.

As far as your 3 day issue goes I was able to reproduce similar results. Here is what I suspect is happening. If you tell Exchange the start time is 7am and end time is 8am, and flag it all day, it will automatically set the start and end times to yyy-mm-ddT00:00:00 and yyy-mm-dd+1T00:00:00. So if I send an appointment for 2011-11-04T07:00:00 to 2011-11-05T07:00:00 w/o the timezone element, it thinks I'm trying to span two days. The start time 2011-11-04T07:00:00 becomes 2011-11-04T00:00:00 to 2011-11-05T00:00:00. The end time 2011-11-05T07:00:00 becomes becomes 2011-11-05T00:00:00 to 2011-11-06T00:00:00. This gets thrown on the calendar as UTC. When viewed it in Outlook or in webapp it displays it in PST as Nov 3rd 5pm - Nov 6th 5pm and looks like its spanning 3 days (but only actually only 48 hours).

0
votes

You need to specified MeetingTimeZone(for ES2007) or StartTimeZone(for ES2010+). I had the same problem, and it helped me.