immutable-ics

immutable-ics copied to clipboard

I'm in UTC+2 right now. For me, the implementation of the DATE transform decreases the day of any given Date by one. So DATE(new Date(2017, 8, 29)) resolves to '20170928' which is clearly not what I want.

I think removing the time zone offset in that function is misplaced.

Yeah, you're right. It's probably best to offload timezone handling to another package that does it well.

Sorry, I don't have much time to investigate right now, but let me know if you have any suggestions (or even a PR 😄 ). I should have some time in a couple of days to take a look at this.

I would probably not do any timezone handling and let the user deal with it. On the other hand, I'm not completely sure what the vCalendar spec says about timezones. Can you explicitly specifiy them? Is there a default?

There's a VTIMEZONE component that allows one to define a timezone.

Definition in RFC 5545: https://tools.ietf.org/html/rfc5545#section-3.6.5

Example:

BEGIN:VTIMEZONE
TZID:America/New_York
LAST-MODIFIED:20050809T050000Z
BEGIN:STANDARD
DTSTART:20071104T020000
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20070311T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
END:DAYLIGHT
END:VTIMEZONE

Unfortunately, using VTIMEZONE adds a lot of work to the user due to the number of required properties. To add to that, I can't think of a time where someone would need to implement a custom timezone that strays from the standard set of timezones (https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).

Here's what I'm thinking:

1. Remove the current naive timezone implementation and require users to add a VTIMEZONE component if needed.
2. Add a large DB of timezones that can be imported easily. Ideally only the imported timezone data would be included in the compiled JS bundle, but that depends on the user's build tools.

Seems pretty straightforward to pull TZ ics files from tzurl.org and parse the necessary bits. https://github.com/mangstadt/biweekly/wiki/Timezones suggests theres a global ID method which seems preferable for use cases which don't need to work for every old calendar client