Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

how to add timeZones ? #198

Open
adarrshpaul opened this issue Aug 26, 2021 · 6 comments
Open

how to add timeZones ? #198

adarrshpaul opened this issue Aug 26, 2021 · 6 comments

Comments

@adarrshpaul
Copy link

adarrshpaul commented Aug 26, 2021

How to add timezones in ics content ?

@patchrobe
Copy link

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.

@patchrobe
Copy link

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.

@adarrshpaul
Copy link
Author

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

jeremiak added a commit to jeremiak/sac-region-calendar-feed that referenced this issue Mar 27, 2023
jeremiak added a commit to jeremiak/sac-region-calendar-feed that referenced this issue Mar 27, 2023
jeremiak added a commit to jeremiak/sac-region-calendar-feed that referenced this issue Mar 27, 2023
@bddvlpr
Copy link

bddvlpr commented Sep 21, 2023

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.

@Caperious
Copy link

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

@bddvlpr
Copy link

bddvlpr commented Feb 14, 2024

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants