how to add timeZones ?

[Adarrsh Paul]

How to add timezones in ics content ?

[Dan Dissanayake]

I find it easiest to create the date in local timezone using something like moment-timezone, convert it to UTC and then use the startInputType parameter e.g.

const ics = require('ics');
const moment = require('moment-timezone');

const event = {
	start: moment.tz("2013-11-18 22:30", "Asia/Taipei").utc().format('YYYY-M-D-H-m').split("-").map(val => parseInt(val)),
	startInputType: 'utc',
	duration: { hours: 1, minutes: 0 },
	title: 'My timezone event',
}

const { error, value } = ics.createEvent(event);

console.log(value);

This outputs:
_
BEGIN:VCALENDAR
VERSION:2.0
CALSCALE:GREGORIAN
PRODID:adamgibbons/ics
METHOD:PUBLISH
X-PUBLISHED-TTL:PT1H
BEGIN:VEVENT
UID:VVE_R4SY-k9OID55TkGZc
SUMMARY:My timezone event
DTSTAMP:20210827T172400Z
DTSTART:20131118T143000Z
DURATION:PT1H
END:VEVENT
END:VCALENDAR
_

As you can see, the DTSTART entry ends with Z to indicate it is in UTC / Zulu time, which makes it explicit exactly when the event starts. Client software will then typically convert this back to the user's local timezone before it is displayed.

[Dan Dissanayake]

startInputType, endInputType will default to local and startOutputType, endOutputType will default to utc.

So, you could just provide the start and end parameters which would be assumed to be in the timezone set in the local environment and they would be converted to UTC/Zulu time automatically for you for display in the output.

I typically fetch stuff from backend data sources for processing in Lambda functions etc so I usually need to be explicit about what zone the data is defined in and regularly can't be sure where it will be executed. If you are, for example, running this in a browser, and accepting a user input it would likely be better to use the default behaviour. Clients consuming the feed should nearly always understand the Zulu format.

[Adarrsh Paul]

This clears up my confusion, thanks for the quick response.

[Luna Simons]

Seems like services including Google (🙄) incorrectly parse the start- and endtime. Our service currently runs in a UTC+2 zone and all dates are in said format. After converting them to UTC google still adds 2 hours eventually to “compensate for the user’s timezone”. I’ll look into implementing the TimeZone Identifier to properly handle this.

[David Rudman]

@bddvlpr This was probably not implemented, since i cant find anythinng about it in the documentation?

[Luna Simons]

@bddvlpr This was probably not implemented, since i cant find anythinng about it in the documentation?

Instead of supporting the timezone attribute, I just changed the output to utc, while keeping input local. Seems to be correctly handled by all ICal servers I’m currently supporting.