kewisch / ical.js Goto Github PK

The draft is not public yet, but if possible I'd like to add support for it so I can mention this implementation in the draft. Notable changes are:

["geo", {}, "float", [123.456, 123.456]],
["request-status", {}, "text", ["3.1", "Invalid property value", "DTSTART:96-Apr-01"]],
["rrule", {}, "recur", { "freq": "MONTHLY", "byday": ["MO","-1TU","3WE"], "bymonthday": [2,3,4] }],

Especially the RRULE part will probably be very easy to do, we just have to move the fromString code from recur.js to design.js. I have part of this already done.

Some questions that have come up regarding the recur type:

• Should we still be keeping the separation between parts and options?
• Does gaia need compatibility so that it also understands a string value? Any other sort of compatibility?
• Do we still need the fromString method? It would probably be nice for consistency, but I see no direct use for it anymore.

Personally I'm not too happy about special casing geo/request-status, but this was requested and I guess I can see a use for it. Its just kind of weird that the text/float value has an array as a value.

@kewisch Agree?

One of the Lightning unit tests is hanging with ical.js, I've created an equivalent testcase for ical.js. The core issue in libical can be seen in bug 356207.

I've tried to apply the fix to ical.js, but its not changing anything. Maybe I did something wrong.

ES6 feature should be removed

var one, two = [1, 2];

Gaia stores the output of ICAL.parse directly. The assumption is that format will very rarely (if ever) change and is considered a major revision. As I would consider ICAL.js "pre-release" we have the opportunity now to change the output to something more optimal if that is possible or desired.

This one is quite easy, as its really just Object.keys(this.jCal[1]), but I think its better to expose this as a method than to mess around with the inner jCal member.

Lightning can make use of this in its getFirst/NextParameterName iterator methods.

If #63 is taken into account, this method should also return the VALUE parameter in case the property is not using its default type.

Monthly recurring events without BYMONTHDAY occur on the first of the month, instead of the same day as the first occurrence.

See also https://bugzilla.mozilla.org/show_bug.cgi?id=1103187

This line looks suspect: https://github.com/mozilla-comm/ical.js/blob/6899a41b572de08d65ab544b51e0a93581bec197/lib/ical/recur_iterator.js#L761

It would be very cool to have some basic performance tests so we can collect data on performance over time.
I am thinking some basic structure where we have a set of files that never change and benchmark parse time & parse + decorate time (and maybe separate cases where they turn back into strings).

This should be fairly easy to hook up /w a custom mocha runner.

@kewisch We touched on this briefly. I believe the idea was to have a warning collection with the optional capability of turning those warnings into errors (or the other way around) right now we throw a lot of errors.

An example of this that I ran into recently is utc offset -0000 which was assigned an error where I believe a warning would have been better. I found that Yahoo (when in etc/gmt) will return this offset. I removed the error in my development branch.

I would like to have a single "vendorable" file to include in a browser environment.
Usually this involves a simple make step that merges all files in the correct order and then optionally minify.

I'm not exactly sure what is happening here, but when trying to upgrade ical.js we are running into a test failure. Our test component looks like this:

[ [ 'prodid',
    {},
    'text',
    '-//Google Inc//Google Calendar 70.9054//EN' ],
  [ 'version', {}, 'text', '2.0' ],
  [ 'calscale', {}, 'text', 'GREGORIAN' ],
  [ 'x-wr-calname', {}, 'unknown', '[email protected]' ],
  [ 'x-wr-timezone', {}, 'unknown', 'America/Los_Angeles' ] ]

On which we do:

var comp = new ICAL.Component(expectedComponent);
var timezone = comp.getFirstSubcomponent('vtimezone');

Timezone is now null, so I'm assuming that the x-wr-timezone is failing to be parsed.

I was a bit surprised that startOfWeek and endOfWeek does not return a date like endOfMonth and startOfYear. Is that on purpose? If not I would happily create a pull request for it.

I have a lot of my own tooling to do this these days from marionette js client (which has tests that run on chrome, firefox, xpcshell, nodejs).

I think we need to discuss this first.

@kewisch

Here's why: http://web.mit.edu/jwalden/www/isArray.html

In the process of writing tests for icalrecur I found some issues with by day rules

FREQ=WEEKLY;COUNT=10;WKST=SU;BYDAY=TU,TH
FREQ=YEARLY;UNTIL=20150131T090000Z;BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA

Working on it now, here for tracking

Hey @kewisch can you add @KevinGrandon so he can be bugged by issues/merge stuff?

I am still on PTO not really watching closely...

This is bug 941425 on Mozilla comm-central.
With rules such as:
RRULE:FREQ=YEARLY;BYMONTHDAY=-1;BYMONTH=2
RRULE:FREQ=YEARLY;BYMONTHDAY=-1
the occurrences happen on wrong days and/or months.

If you run the validator from Chrome you will get an error saying that toSource is not defined. I don't know if this is just intentional, if is you should probably mention that the validator is Firefox only in the readme.

Object.prototype.toSource
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/toSource

When parsing then creating a component will be mutated. This means if you wish to parse pull out some data but save the original structure you have to call toJSON on the component to create a clean copy.

I think we could clone? The original objects so we don't mutate them during component creation I don't have a test case for this I merely observed it while writing some tests for my gaia code.

Remove "for each" / E4X xml stuff

@kewisch What do you think? I think this lib is very valuable outside of a gecko environment at minimum I would like to have it working in chrome/node/firefox/b2g.

Also I believe this throw errors while in strict mode which is on by default in b2g dev mode.

Hi,

Again me ... Sorry.
I wonder if we could set a "custom" organizer like ORGANIZER;CN=Sebastien:mailto:[email protected] ?

It would be great, I could remove "Unknown Organizer" on my ICS invitation.

Seb

Hi There,

I'm sorry to bother you, I just started to work with ICS. And Thanks god, I found your lib.
However, I can't make it work.

Here's my error :

TypeError: Cannot read property 'tzid' of undefined
    at Object.ICAL.Event.Event._setTime (/app/node_modules/jsical/build/ical.js:6504:44)
    at Object.startDate (/app/node_modules/jsical/build/ical.js:6407:12)
    at getICS (/app/lib/routes/bookings.js:123:21)
    at wrapICS (/app/lib/routes/bookings.js:84:12)
    at tryCatcher (/app/node_modules/bluebird/js/main/util.js:24:31)
    at Promise._settlePromiseFromHandler (/app/node_modules/bluebird/js/main/promise.js:466:31)
    at Promise._settlePromiseAt (/app/node_modules/bluebird/js/main/promise.js:545:18)
    at Promise._settlePromises (/app/node_modules/bluebird/js/main/promise.js:661:14)
    at Async._drainQueue (/app/node_modules/bluebird/js/main/async.js:79:16)
    at Async._drainQueues (/app/node_modules/bluebird/js/main/async.js:89:10)
    at Async.drainQueues (/app/node_modules/bluebird/js/main/async.js:14:14)
    at process._tickCallback (node.js:419:13)

I watched the code, and I guess it's the line prop.setParameter('tzid', time.zone.tzid); in _SetTime.
And it seems logical, because I'm doing something like this to set up my start and end date :

event.startDate = new Date("2015-03-19T17:00:00");

And there is no startDate.zone in it.
I think that's a doc problem ? Or I may be an asshole. It happens sometime. 😉 😛

Someone can Help me ?

Seb

Hi,
Is this lib node.js compatible?
I tried to install it but the lib/index.js the package.json refers to is missing and I'm getting the following error when using require for the lib (I renamed the lib to mzc-icaljs locally for I have another ical module installed)

module.js:340
    throw err;
          ^
Error: Cannot find module 'mzc-icaljs'
    at Function.Module._resolveFilename (module.js:338:15)
    at Function.Module._load (module.js:280:25)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)

thank you in advance for your attention

The below is a snippet from PST "STANDARD" VTIMEZONE sub-component.

var raw = 'FREQ=YEARLY;BYMONTH=3;BYDAY=2SU';
var start = '19700308T020000';
var recur = ICAL.icalrecur.fromString(raw);
var start = ICAL.icaltime.fromString(start);

var iterator = recur.iterator(start);

Working on this now...

Example:

TRIGGER;VALUE=DATE-TIME:20120903T233000Z

I have some iCal-data with a timezone-definition (Europe/Copenhagen; CET/CEST), but I can't get the dates specified in this timezone out in UTC.

Roughly:

BEGIN:VTIMEZONE
TZID:Europe/Copenhagen
...
END:VTIMEZONE
BEGIN:VEVENT
...
DTSTART;TZID=Europe/Copenhagen:20131120T113000
...
END:VEVENT

When I parse it, I it seem to believe the UTC-offset is 0, no matter how I poke at it.

event = new ICAL.Event(
    ICAL.Component(ICAL.Parse(DATA)[1]).getFirstSubcomponent('vevent')
);

event.startDate.toJSDate();
// In computer localtime.

event.startDate.utcOffset();
// 0 - should be 1 or 2 hours, depending on summertime.

console.log(event.startDate);
{ wrappedJSObject: [Circular],
  _time: 
   { year: 2013,
     month: 11,
     day: 20,
     hour: 11,
     minute: 30,
     second: 0,
     isDate: false },
  _pendingNormalization: false,
  timezone: 'Europe/Copenhagen',
  zone: 
   { wrappedJSObject: [Circular],
     expandedUntilYear: 0,
     changes: [],
     tzid: 'floating' } }

Can anyone give some pointers as to what I'm doing wrong?

Also: How do I generate startTime and endTime with timezone-definitions? ICAL.Time.fromData({...}, iCalTz) doesn't add the timezone-definition...

Performance is not a big concern of mine right now but I think it would be cool to have a benchmark structure like this:

/benchmarks/
  /versions/
     /ical_v1.js
     /ical_v2.js
     /ical.js

  small_bench.js

The full benchmark suite will then run on all versions and report the differences.
Obviously this will break if we change API's but I think there is long term benefit from tracking our parsing times.
I would guess things like ICAL.parse may eventually change return format but the api will likely never change.

Take this example

BEGIN:VCALENDAR
X-FOO;PARAM1=VAL1:FOO;BAR
END:VCALENDAR

Result is:

[
 "vcalendar",
 [
  [
   "x-foo",
   {
    "param1": "VAL1:FFF"
   },
   "unknown"
  ]
 ],
 []
]

Expected:

[
 "vcalendar",
 [
  [
   "x-foo",
   {
    "param1": "VAL1"
   },
   "unknown",
   "FOO;BAR"
  ]
 ],
 []
]

(or [ "FOO","BAR" ] it the property has been declared with the structuredValue property into ICAL.design.property)

Was originally going to expose this on the parser but one of the benefits of the new component structure is we will eventually be able to remove the dependency on the parser in the component layer (for pure jCal files) so we may not want to directly tie those.

http://freeassociation.svn.sourceforge.net/viewvc/freeassociation/trunk/libical/src/libical/icaltimezone.c?r1=1148&r2=1147&pathrev=1148

http://tools.ietf.org/html/rfc5545#page-23

While investigating #99 I noticed that when iterating over the recurring event in samples/recur_instances.ics iterator.next() is returning

• Oct 2, 2012 (correct)
• Nov 5, 2012 (one day too early)

It should be returning the 1st Tuesday of each month.

A recurrence on 29th Feb each year like this:
RRULE:FREQ=YEARLY
DTSTART;TZID=Europe/Berlin:20120229T120000
DTEND;TZID=Europe/Berlin:20120229T130000

shows up on Mar 1st in non-leapyears.

Since the ical-spec says, that BYMONTHDAY parts > daysInMonth should not show, this should also apply to this special case.

It is useful to create a CONTRIBUTING.md document on github.

@kewisch

I have seen both is_by_count and addComponent I personally prefer addComponent (camelCase over snake_case)

I am willing to offer bribes to move to 2 spaces over 4 as well :)

We should support http://tools.ietf.org/html/rfc6868, possibly optional. Creating this issue for tracking.

The current timezone implementation is fairly slow (took around 120ms to take an VTIMEZONE for PST and process it on my MBP).

We touched on this but I think its going to be really valuable to pre-build the timezone objects as its own JS file and then we can loaded it as needed. We can then improve the existing logic for determining the UTC offset by to increase / decrease the year coverage.

I think they may also be value to (at built time) determine which years related to which "changes" for example PST daylight savings start in March and then standard resumes in November so we have 3 set of "changes" to go through vs every change of all time (86) per year. These performance gains may be minimal but I suspect when the rules are more complicated there could be major savings here.

Just so I don't forget, noticed this on the way. The simple patch looks like this:

diff --git a/lib/ical/ical.js b/lib/ical/ical.js
index a5920b5..29014ed 100644
--- a/lib/ical/ical.js
+++ b/lib/ical/ical.js
@@ -599,9 +599,6 @@ ICAL.design = (function() {
       },
       float: {
         matches: /^[+-]?\d+\.\d+$/,
-        decorate: function(aValue) {
-          return ICAL.Value.fromString(aValue, "float");
-        },

         fromICAL: function(aValue) {
           var parsed = parseFloat(aValue);

Needs tests of course.

When using ICAL.js in Lightning, I try to just forward the methods from the xpcom interface to ICAL.js. One of the cases that don't work out is get/set/removeParameter. Lightning interfaces were written with iCalendar in mind, so prop.getParameter("VALUE"); is a valid thing to do. This doesn't translate well to ICAL.js since the value type is no longer a real parameter.

On one hand, the API is correct if based on jCal, since VALUE is not a real parameter. On the other hand, developers used to iCalendar could expect it to be returned, so we might want to add special case code if the VALUE parameter is requested:

• getParameter: Return the type, iff the default type does not match the current type
• setParameter: don't set the parameter in jCal, instead call resetType() attempting to preserve the property value
• removeParameter: call setParameter('value', defaultType), which will remove it at least for getParameter's eyes.

I am 100% sure ICAL.js does not work (Time likely does not work) with IE8. I personally don't have a stake there. I think we should conform to ES5 (whatever is 100% ES5 will run ICAL.js).

I don't know if I'm missing something, or is it a bug that dayOfWeek normalizes to Sunday:

// Normalize to 1 = sunday
h = ((h + 6) % 7) + 1;

If it is a bug, I would happily try to fix it; otherwise you can close the issue.