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
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>
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):
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>
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).
You need to specified MeetingTimeZone(for ES2007) or StartTimeZone(for ES2010+). I had the same problem, and it helped me.
Related
I am laying bets through the Betfair API and noticed something very strange. For some events the time is off on both market and event results.
My account date and time are set to Europe/London. Not that it matters, the API outputs whatever zone it wants anyway, apparently at random (sometimes GMT other times London or whatever other timezone, but the ISO timestamp does not include +0100 or whatever GMT offset), all this despite the fact that my account is set to EU/London.
For example let's take this event Superettan / Jonkopings Sodra v Varnamo
The API output is:
{"event"=>{"id"=>"28836884",
"name"=>"Jonkopings Sodra v Varnamo", "countryCode"=>"SE",
"timezone"=>"GMT", "openDate"=>"2018-08-13T18:00:00.000Z"
}, "marketCount"=>2}
Their website however says the event starts at 17:00 GMT / 18:00 London (now GMT+1).
There are hundreds examples like this. Cannot get anything out of Betfair support, they take days/weeks to reply and when they do they just send some canned message.
Has someone seen this issue before? Or perhaps I am missing something?
Later edit: I had to dump all their market data to reach this conclusion: it appears that when their API says the timezone is GMT the event is actually on London, so GMT+1 right now, and for every other timezone (Eu/London, Perth, US...) the time is actually on GMT. Not sure what's up with that. Still investigating.
All times returned by Betfair are in UTC - that's just the way the API works. They also supply time zones which may or may not be correct. Use the time zones as an indication of the local time of the event. However, the time zones are very "hit and miss", so don't rely on them to be correct. In fact, over time you will notice lots of "data errors" for non-pricing info on Betfair markets. This is just the way it goes. so don't expect them to fix the errors
Event.openDate is documented as "The scheduled start date and time of the event. This is Europe/London (GMT) by default" while Event.timezone is defined as "[the] timezone in which the event is taking place."
So, in one sense, the openDate in your API output is correct because it says 18:00. However, it's incorrect because it includes the Zulu 'Z' suffix indicating GMT / UTC. The inclusion of 'GMT' in the timezone field: a) is wrong; and b) just serves to confuse matters, IMHO.
Instead, I've started to use MarketCatalogue.marketStartTime which is defined as "The time this market starts at..." which isn't quite the same as openDate but, if they're going to be different, usually on Betfair you're more interested in when the market goes in-play than when the actual match / race / game begins.
The Events I'm using to validate this approach seem to work better this way. Bearing in mind that the UK moves from BST on 27 October to GMT on 28 October, from the API I'm receiving these as MarketCatalogue.marketStartTime:
Liverpool v Cardiff: "2018-10-27T14:00:00.000Z" [Correct: 14:00 GMT is 15:00 BST]
F1 Mexico Grand Prix [qualifying]: "2018-10-27T18:00:00.000Z" [Correct: 18:00 BST is 19:00 GMT]
Burnley v Chelsea: "2018-10-28T13:30:00.000Z" [Correct: 13:30 GMT is 13:30 GMT]
I want to fetch record from the sys_user table which is updated at or after certain time stamp.
for that I have created rest request as
https:/service-now.com/api/now/v1//table/sys_user?sysparm_query=sys_updated_on>=javascript:gs.dateGenerate('2017-10-30','01:25:00')
I had converted current time which is in IST format into GMT and pass it to dateGenerate() function.
Problem statement -
I don't want to convert the IST to GMT, is there any way by which i can identify ServiceNow instance time zone at runtime and convert given time into that time stamp and get the users.
If i can pass this date and time in UTC format.
Ahoy!
This is a great question, and something that's quite difficult in ServiceNow (dealing with time-zones).
As such, I've written a tool to manage this for you. It's totally free!
The tool is called TimeZoneUtil, and can be found here:
https://snprotips.com/blog/2017/9/12/handling-timezones-in-servicenow-timezoneutil
You simply need to initialize a GlideDateTime object, set its' time-zone to IST, use setDisplayValue() to set its' time based on IST current time, then use .getValue() to get that same time in system time.
This is because getDisplayValue()/setDisplayValue() work based on time-zone, whereas setValue()/getValue() always return the corresponding system time.
EDIT: In order to make this a little more clear, I'll provide some example usage below.
var tz = new TimeZoneUtils(); //initialize with current time
gs.print(tz.getOffsetHours()); //prints out "-7" in my instance, as the system time is in Pacific.
tz.setTimeZone('Asia/Kolkata'); //sets the time-zone to IST/UTC+5.5
gs.print(tz.getOffsetHours()); //prints "5.5".
gs.print(tz.getGDT().getDisplayValue()); //Prints the current time in IST (2017-11-01 20:52:31 at the moment).
gs.print(tz.getGDT().getValue()); //Prints the current time in system time (2017-11-01 15:23:12 at present).
gs.print(new TimeZoneUtils().setTimeZone('Asia/Kolkata').getDisplayValue()); //Single line, also prints current time in IST: 2017-11-01 20:52:31
The first 6 lines there, demonstrate basic usage and explain how it works.
The eighth line however, demonstrates usage on a single line, which you can use inside a query string. For example:
sysparm_query=sys_updated_on>=javascript:new TimeZoneUtils().setTimeZone('Asia/Kolkata').getDisplayValue()
Hope this helps!
Tim Woodruff
Author, Learning ServiceNow & Building Powerful Workflows
Owner/Founder, SN Pro Tips
Context
I have multiple servers listening to a specific collection (/items). Each of them use NTS for time calibration and the ".info/serverTimeOffset" to measure the expected time difference with Firebase. It is consistently around 20ms.
I have many clients pushing items to the collection with the specific field:
{
...
created: Firebase.database.ServerValue.TIMESTAMP
}
What is expected:
When the server receives the item from Firebase and subtracts the item.created with the Firebase expected time (Date.now() + offset), this value should be positive and probably around 10ms (time for the item to be sent from Firebase to the server).
What is happening:
When the server receives the items, the item.created field is superior to the Firebase expected time. Like it was created in the future. Usually the difference is around -5ms
Question:
What is the Firebase.database.ServerValue.TIMESTAMP set to ? and how is it related to the ".info/serverTimeOffset" ?
The 27th September 2016 at 1am UTC, that difference jumped from -5ms to around -5000ms like a kind of re-calibration happened (it lasted until I reset the .info/serverTimeOffset) Did someone experienced something similar?
We are adding event with start time and end time like below snippet,
EventDateTime startEventDateTime = new EventDateTime().setDateTime(startDateTime).setTimeZone(timeZone);
EventDateTime endEventDateTime = new EventDateTime().setDateTime(endDateTime).setTimeZone(timeZone);
If the timeZone is either "Asia/Calcutta" or "GMT +05:30", it will be added in Google Calendar successfully, but some of our users' timezone is like "IST","PST","CST". If we give it in timeZone variable, Google Calendar throws
"Invalid time zone definition for start time."
Is it possible to accept even if the timezone is like "IST","PST","CST","EST"?
Time Zone should be in same format as shown in Google Calendar time Zone link.
For compatibility with JDK 1.1.x, some other three-letter time zone IDs (such as "PST", "CTT", "AST") are also supported. However, their use is deprecated because the same abbreviation is often used for multiple time zones (for example, "CST" could be U.S. "Central Standard Time" and "China Standard Time"), and the Java platform can then only recognize one of them. So just because of this Google might not accept the Three-letter time zone IDs.
I have a program that sends calendar appointments out to users. However these users are in many different time zones. When I create the .ics file, I set the time zone to the local time zone, because they are scheduled here. They then get sent out to the users, who are scattered across many time zones.
Will outlook handle this correctly? As in: if I schedule a person for an 8am meeting and I am in Philadelphia, it should come up as 8am meeting for them in any other time zone.
I know that Outlook works with time zones to an extent, but I couldn't find any good documentation on it.
EDIT:
I really should have asked something more along the lines of how do you format it to handle this correctly, here is the format I am currently using. But I have little experience with this so I might be doing it wrong:
String[] iCalArr = { "BEGIN:VCALENDAR",
"PRODID:-//foobar//morefoobar//EN",
"VERSION:2.0",
"CALSCALE:GREGORIAN",
"METHOD:REQUEST",
"BEGIN:VTIMEZONE",
"TZID:America/New_York",
"X-LIC-LOCATION:America/New_York",
"BEGIN:DAYLIGHT",
"TZOFFSETFROM:-0500",
"TZOFFSETTO:-0400",
"TZNAME:EDT",
"DTSTART:19700308T020000",
"RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU",
"END:DAYLIGHT",
"BEGIN:STANDARD",
"TZOFFSETFROM:-0400",
"TZOFFSETTO:-0500",
"TZNAME:EST",
"DTSTART:19701101T020000",
"RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU",
"END:STANDARD",
"END:VTIMEZONE",
"BEGIN:VEVENT",
"DTSTART;TZID=America/New_York:" + strBeginDate,
"DTEND;TZID=America/New_York:" + strEndDate,
"DTSTAMP:" + strNow,
"UID:DT 2012 Training - " + System.Guid.NewGuid().ToString(),
"RECURRENCE-ID;TZID=America/New_York:20110207T103000",
"CREATED:" + strNow,
"DESCRIPTION;ENCODING=QUOTED-PRINTABLE:foobar",
"LAST-MODIFIED:" + strNow,
"LOCATION:" + location,
"SEQUENCE:1",
"STATUS:TENTATIVE",
"SUMMARY:foobar",
"TRANSP:OPAQUE",
"END:VEVENT", "END:VCALENDAR" };
Outlook should handle that just fine, assuming your particular application writes out proper timezone information. Or perhpaps works in UTC and marks everything with the Z zone.
I'm confused by your remark that "testing is not an option". I can imagine the unidentified "program" being unable to write out test data, but your question indicates you worry about Outlook. Surely you can handedit some ICS files with different timezones and feed them to Outlook? This should clearly indicate that Outlook knows how to deal with them.
yes Outlook handles time zones, this article from the KB actually indicates a limitation which is that Outlook needs to be updated everytime a timezone (DST, ...) is changed:
http://support.microsoft.com/kb/931667