How can you set a timezone in an outlook.com link? - email

I'm trying to set correct times for an Outlook event in the UK, but Outlook seems to set the incorrect time for BST (British Summer Time).
Here is a link, which creates an event for 19th June 2017 at 1254pm to 1257pm.
In my Outlook it opens an hour ahead as 1354pm. Is there a way to explicitly set the timezone in the link?
I've tried checking my settings and using a different Outlook account so I don't think it's an issue with my mail/calendar settings.
https://bay02.calendar.live.com/calendar/calendar.aspx?rru=addevent&dtstart=20170619T125400&dtend=20170619T125700&summary=Summary+of+the+event&location=Location+of+the+event&description=example+text.&allday=false&uid=

After researching quite I've realised that Outlook always expresses time in UTC when sending a link. Therefore you need to convert the date/time from BST to UTC. You can do this with PHP like this:
$date = new DateTime('2017-06-22T12:54', new
DateTimeZone('Europe/London')); /* <-- Time zone to be converted */
echo $date->format('YmdHis') . "\n";$date->setTimezone(new
DateTimeZone('UTC'));echo $date->format('YmdHis') . "\n"; /* <-- New time zone, UTC */

Related

Google Calendar api ignores timezone

Im using the CalendarApi in flutter and in order to get events I use the list method like that:
calendarApi.events.list(
cls.calendarId,
timeZone: <specific timezone>
timeMin: DateTime.now().today().toUtc(),
timeMax: DateTime.now().tomorrow().toUtc(),
),
No matter what timezone I tried it always return the event start and end date in UTC format.
I tried using the timezones in multiple formats:
America/Los_Angeles
UTC - 08:00
GMT format
Pacific Standard Time
None of the following worked.
In addition in the in google calendar's settings the timezone is set correctly.
From the documentation:
Must be an RFC3339 timestamp with mandatory time zone offset, for example, 2011-06-03T10:00:00-07:00, 2011-06-03T10:00:00Z. Milliseconds may be provided but are ignored. If timeMax is set, timeMin must be smaller than timeMax.
Make sure the strings you are sending follow one of these pattens:
YYYY-MM-DDTHH:MM:SS±HH:MM
or
YYYY-MM-DDTHH:MM:SSZ
So for example, the time that this answer was posted would be:
2021-07-27T16:08:02+02:00
or:
2021-07-27T14:08:02Z
Where the Z signifies 'Zulu', or UTC.

Timezone issues returning a date object to a Google Sheets spreadsheet

I'm writing a custom function to return financial quotes obtained from Yahoo Finance to a Google Sheets spreadsheet (the built-in GoogleFinance() won't cut it for various reasons), and I'm having problems to return a Date object containing the date and time of the quote. https://developers.google.com/apps-script/guides/sheets/functions says that "Times and dates in Sheets become Date objects in Apps Script. If the spreadsheet and the script use different time zones (a rare problem), the custom function will need to compensate", but it's not clear how.
First of all, the timezone of my browser is "asia/hong_kong", i.e. GMT+0800 (HKT). It turns out that the script somehow knows that, because when I format a Date object built with d = new Date(2016,5,24,0,0,0,0) with d.toString() I get "Wed Jun 24 2016 00:00:00 GMT+0800 (HKT)". This is weird, because SpreadsheetApp.getActiveSpreadsheet().getSpreadsheetTimeZone() actually returns "America/Los_Angeles", indicating that the server is on the West Coast of the US: so why does the method toString(), which is run on the server side, format the date according to the Hong Kong time? This sounds like a bug to me.
Anyway, the biggest problem I'm having is that when the custom function returns the date object to the spreadsheet, if I format the cell with Format -> Number -> Date time, what I see displayed is "23/06/2016 09:00:00", i.e. the date and time on the US West Coast when the Hong Kong date and time are the ones I specified through the parameters passed to the constructor (corresponding to Wed Jun 24 2016 00:00:00).
Then I tried to build the Date object with new Date(Date.UTC(2016,5,24,0,0,0,0)), but (predictably enough) now the spreadsheet displays "23/06/2016 17:00:00", which is the date and time on the West Coast when the UTC date and time are the ones I specified.
So, how do I get a Date object that, once returned to the spreadsheet, shows exactly the same date and time I used to build it? I tried to change the spreadsheet's timezone to UTC using ss.setSpreadsheetTimeZone("Etc/UTC"), but then unfortunately the script returns the error "You do not have permission to call setSpreadsheetTimeZone"...
This is the kludgy solution I managed to write (but I hope there is a better way):
// hours and minutes contain values obtained from the text quote; the date is in the string variable:
// date_str = "05/24/2016";
var tz = SpreadsheetApp.getActiveSpreadsheet().getSpreadsheetTimeZone(); // this returns the TZ of the server, "America/Los_Angeles"
var ums = Date.parse(date_str+" UTC");
var offset = Date.parse(Utilities.formatDate(new Date(ums), tz, "MM/dd/yyyy HH:mm:ss") + " UTC") - ums; // time in LA - UTC time in ms
var d = new Date(Date.parse(date_str));
d = new Date(Date.UTC(d.getFullYear(),d.getMonth(),d.getDate(),hours,minutes,d.getSeconds())-offset);
return d;

Importing ICS into Google Calendar with correct timezone

I'm trying to import a simple ics file into Google calendar. However, even though I have the timezone specified, Google calendar still imports the wrong event time. (Although it does say that the wrong time is in the correct timezone.)
Here is a sample of my ics file:
BEGIN:VCALENDAR
BEGIN:VEVENT
DESCRIPTION: Test_Description
DTEND;TZID=US-Pacific:20140606T180000
DTSTART;TZID=US-Pacific:20140606T170000
LOCATION:Test_Location
SUMMARY:Test_Summary
UID:20140606T150000#NL
END:VEVENT
END:VCALENDAR
This event should show up as occurring on June 6, from 5PM-6PM Pacific Standard Time. However, on my calendar it shows up as occurring on June 6, from 10AM-11AM PST.
I think (although have not implemented) a hack to just change everything to UTC and adjust the event time accordingly might work. However, this would be a little annoying to implement and honestly Google Calendar should be able to handle this simple of an import.
Does anyone have any suggestions to deal with this, or see any bugs in my ICS file?
Thanks!
To make your ICS work with Google's "Add by URL..." specify your timestamps in UTC and add the X-WR-TIMEZONE. Timestamp must have the Z at the end to mark the timestamp as UTC:
DTSTART:20140102T110000Z
Also add the timezone specification in the VCALENDAR block like this:
X-WR-TIMEZONE:Europe/Zurich
After adding the calendar in Google Calendar, the time zone for should be set correctly in the calendar's settings.
If you are using PHP to generate the ICS, you can convert the timestamps to UTC like this:
// The timestamp in your local time and your local time zone
$timestamp = "01.01.2016 12:00";
$timezone = new DateTimeZone('Europe/Zurich');
// The UTC timezone
$utc = new DateTimeZone('UTC');
// Create a DateTime object from your timestamp using your local timezone
$datetime = DateTime::createFromFormat("d.m.Y H:i",$timestamp, $timezone);
// Set the timezone on the object to UTC.
$datetime->setTimezone($utc);
// Print the time in UTC and use the correct format for ICS
echo $datetime->format('Ymd\THis\Z');
This also works on Apple's iPhones.
Normally it is required to include VTIMEZONE objects. Many people are starting to omit that, but if you do, at least use an olson-identifier. This should be enough for google calendar to pick up the correct timezone.
An example of an olson identifier is Europe/Amsterdam. Look up the identifier the most appropriate for you. Presumably this is something like America/Los_Angeles.

Converting a string timestamp to Date results in reset to UNIX epoch

I'm having some problems converting a string to a date object in google apps script.
My dates are in the following format, from a 3rd party API:
2013-01-17T17:34:50.507
I am attempting to convert this to a Date object:
return Date(stringDate);
And this is being returned:
Thu Jan 01 01:00:00 GMT+01:00 1970
Can someone tell me what i'm doing wrong, and how to resolve this issue ?
With moment.js, it is as easy as this to parse any of ISO 8601 format.
var date = Moment.moment("2013-01-17T17:34:50.507").toDate();
You can use moment.js to parse your arbitrary date string as well.
To use moment.js in GAS, you just need to add it in the script editor.
Open your script in GAS script editor and go to "Resources" then "Libraries...", then put this project key MHMchiX6c1bwSqGM1PZiW_PxhMjh3Sh48 and click "Add". Choose the version from the dropdown, then click "Save". Now, you are ready to use moment.js in GAS.
moment.js can be used to parse date string, create formatted date string, and many other date manipulation. Thanks to the author!
You can find the moment.js documentation here.
It doesn't appear that the Date object knows how to handle that date. The date is in ISO 8601 format. Javascript can handle Dates if they are given timezone information.
You will have to do some testing, but if those dates given to you are in UTC time, then just add a Z to the end of the date string before you call new Date().
Edit: The Apps Script Date object can't seem to handle a timezone other than UTC when parsing a Date. I opened an issue for it.
It doesn't work in GScript, at least for me at the time I'm writing it.
This post serves a working alternative: How do I format this date string so that google scripts recognizes it?
As of now new Date() seems to work:
var dT = new Date("2013-01-17T17:34:50.507");
console.info("dT: %s or %d", dT, dT.getTime());
returns dT: Thu Jan 17 17:34:50 GMT+01:00 2013 or 1.358440490507E12 in Google Apps Script

How can I shift timezone of Date object created in local timezone to target timezone in GWT client?

How can I shift timezone of Date object created in local timezone to target timezone?
Here is what I need. I want web-client to pick a date using DatePicker but resulting Date object should look like as if it was picked in another timezone. Since there is no way to tell DatePicker to do that I have to manually shift date.
For example it's Apr 6th 2012 2:42AM in California right now. Created Date will be in UTC-7 timezone. I want to have Date object with Apr 6th 2012 2:42AM in Europe/Moscow timezone.
Here is I do it right now:
final TimeZoneConstants constTz = GWT.create(TimeZoneConstants.class);
final TimeZone timeZoneMsk = TimeZone.createTimeZone(constTz.europeMoscow());
final TimeZone timeZoneCali = TimeZone.createTimeZone(constTz.americaLosAngeles());
Date curTime = new Date();
DateTimeFormat dateTimeFormat = DateTimeFormat.getFullDateTimeFormat();
Date mskTime = new Date(curTime.getTime() - (curTime.getTimezoneOffset() - timeZoneMsk.getStandardOffset()) * 60 * 1000);
String strLocal = dateTimeFormat.format(curTime, timeZoneCali); // Friday, 2012 April 06 02:42:59 Pacific Daylight Time
String strMsk = dateTimeFormat.format(mskTime, timeZoneMsk); // Friday, 2012 April 06 02:42:59 Moscow Standard Time
There are two problems with this method:
If you ask me it looks pretty bizarre.
Timezone in mskTime is still -0007. I wonder if it can cause any problems in future when I deserialize this object from Google App Engine datastore.
Or should I just produce string with full date of local Californian time, replace timezone in string and then generate new Date by calling DateTimeFormat.parse() ? It looks pretty hacky too...
Also what do you think of JodaTime for GWT ? Is it stable enough for production ?
Your code looks about right. Using DateTimeFormat.parse might make the intention clearer to a casual reader. It's not very often that you are given timezones A and B and one Date object, and you have to produce a new Date object that, when formatted in B, has the same time as the original when formatted in A.
Timezone in mskTime is still -0007. I wonder if it can cause any problems in future when I deserialize this object from Google App Engine datastore.
No, there can be no problems. Remember that a Date object represents a universal point in time not bound to a timezone. When it's April 6 14:40 in Moscow, it's April 6 03:40 in California, so the Date objects are equal.