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.
Related
I am creating YouTube live broadcast using API explorer everything is working fine but Snippet.scheduledStartTime is not working fine.
My time zone is +05:00 and country is Pakistan.
I want to schedule event at 2019-01-18 04:50 PM. I have set the Snippet.scheduledStartTime to 2019-01-18T11:50:00.000Z but on event page it shows Starts January 18, 2019 at 3:50 AM (PST) when I click edit it shows wrong country and time zone like that United States (GMT -08:00) Pacific
I want to use javascript or php client libraries.
Please let me know how I can fix it?
Here is my php code
$broadcastSnippet = new Google_Service_YouTube_LiveBroadcastSnippet();
$broadcastSnippet->setTitle('New Test Broadcast');
$broadcastSnippet->setScheduledStartTime('2019-01-18T11:50:00.000Z');
According to the YouTube Live Streaming API Docs, the format for scheduledStartTime must be in ISO 8601 format:
datetime
The date and time that the broadcast is scheduled to start.
The value is specified in ISO 8601 (YYYY-MM-DDThh:mm:ss.sZ) format.
I would suggest that you check the time zone designator you have set.
Create date with timezone
I am not a PHP dev but the smartest thing to do IMO would be to create a date in the correct timezone and then out put it in the correct format. After about five minutes of googleing i found this.
$tz = 'Europe/London';
$timestamp = time();
$dt = new DateTime("now", new DateTimeZone($tz)); //first argument "must" be a string
$dt->setTimestamp($timestamp); //adjust the object to correct timestamp
echo $dt->format('c');
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
How do you convert a timezone from int to string (etc: Europe/Stockholm)?
I'm using Facebooks PHP api and that returns ["timezone"] => int(2). How am I suppose to parse that?
How do you convert a timezone from int to string (etc: Europe/Stockholm)?
You can't. Read "Time Zone != Offset" in the timezone tag wiki.
Facebook's documentation explains that the timezone field is the user's timezone offset from UTC.
What it doesn't make clear, but I have found through experimentation, is that it is not necessarily the user's current offset, but it instead it is the offset as of the user's last log in. If the user changes time zones, or daylight saving time begins or ends, that will not be reflected in the Facebook data until the user's next log in.
See also these posts:
Facebook API, timezone and country
FaceBook Time zone and Event Times
You can get the timezone name by using timezone_name_from_abbr("", $value*3600, false);. $value is the timezone offset you get from Facebook.
Thanks to minaz.
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
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.