kewisch / ical.js Goto Github PK
View Code? Open in Web Editor NEWJavascript parser for ics (rfc5545) and vcard (rfc6350) data
Home Page: https://kewisch.github.io/ical.js/
License: Mozilla Public License 2.0
Javascript parser for ics (rfc5545) and vcard (rfc6350) data
Home Page: https://kewisch.github.io/ical.js/
License: Mozilla Public License 2.0
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.
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
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.
@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.
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.
Hey @kewisch can you add @KevinGrandon so he can be bugged by issues/merge stuff?
I am still on PTO not really watching closely...
@kewisch Agree?
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.
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
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.
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.
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.
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:
resetType()
attempting to preserve the property valuesetParameter('value', defaultType)
, which will remove it at least for getParameter's eyes.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:
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.
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.
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...
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)
ES6 feature should be removed
var one, two = [1, 2];
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
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.
We should support http://tools.ietf.org/html/rfc6868, possibly optional. Creating this issue for tracking.
It is useful to create a CONTRIBUTING.md
document on github.
While investigating #99 I noticed that when iterating over the recurring event in samples/recur_instances.ics
iterator.next()
is returning
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.
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
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 :)
Here's why: http://web.mit.edu/jwalden/www/isArray.html
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.
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.
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.
Example:
TRIGGER;VALUE=DATE-TIME:20120903T233000Z
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.
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...
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.
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,
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
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.
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.
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).
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.