tl;dr The Problem
Currently, UTC time is the assumption when it should instead be floating time.
Important Note: This is at the event level, not the calendar level.
Example/Details
To explain let's look at the example_toString.js
file and how it works/behaves:
The JavaScript / Intent
This is the relevant code in the example described above:
event = cal.createEvent({
start: new Date(new Date().getTime() + 3600000),
end: new Date(new Date().getTime() + 7200000),
summary: 'Example Event',
description: 'It works ;)',
organizer: 'Organizer\'s Name <[email protected]>',
url: 'http://sebbo.net/'
});
Specifically, the start
and end
is created with a new Date(new Date.getTime() + delay)
call. These calls are done from the timezone of the computer running the code be it on a server or a user's machine.
It's important to note that this example has not defined a timezone for the event.
Because the code has not yet specified any particular timezone (be it -5 or UTC), the iCal generator should be operating in "floating" timezone mode. Looking at RFC 5545, here is where "floating" mode is defined (3.3.5):
FORM #1: DATE WITH LOCAL TIME
The date with local time form is simply a DATE-TIME value that
does not contain the UTC designator nor does it reference a time
zone. For example, the following represents January 18, 1998, at
11 PM:
19980118T230000
DATE-TIME values of this type are said to be "floating" and are
not bound to any time zone in particular. They are used to
represent the same hour, minute, and second value regardless of
which time zone is currently being observed.
Basically, if we give 2pm as a time, it should store just the 2pm, and not any timezone data at all. This is not going to be the behavior that most want out of the calendar, for the very reasons we have timezones in the first place.
That said, here is what the current library generates:
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//sebbo.net//ical-generator//EN
BEGIN:VEVENT
UID:[email protected]
SEQUENCE:0
DTSTAMP:20170110T023408Z
DTSTART:20170110T033408Z
DTEND:20170110T043408Z
SUMMARY:Example Event
DESCRIPTION:It still works \;)
ORGANIZER;CN="Organizer's Name":mailto:[email protected]
URL;VALUE=URI:http://sebbo.net/
END:VEVENT
END:VCALENDAR
Paying special attention to the dates, we can see that the start time is defined as 20170110T023408Z
. This is in fact the correct time (I ran it at around 10pm EST). This causes some unique behavior from programs like MS Outlook, which gives a warning when it does the UTC conversion, which may not be what somebody wants in their end product.
This format is instead in the format of UTC, as defined in the RFC (3.3.5) as follows:
FORM #2: DATE WITH UTC TIME
The date with UTC time, or absolute time, is identified by a LATIN
CAPITAL LETTER Z suffix character, the UTC designator, appended to
the time value. For example, the following represents January 19,
1998, at 0700 UTC:
19980119T070000Z
The "TZID" property parameter MUST NOT be applied to DATE-TIME
properties whose time values are specified in UTC.
The Solution / Proposed Fix
I would like to see an option to support both timezones and UTC. I imagine that this could be done by assuming floating when the timezone is null
and a new boolean value for UTC is set to false
.
In such a system, I imagine that the library would need to throw an exception when UTC is set to true
and the timezone is not null
. An alternative would be to simply ignore UTC if there is a timezone set and not throw an exception.