Additional maintainers?..

[kibertoad]

Considering the decrease in the activity of this project, would you be open to inviting additional maintainers?

[spacegangster]

Also, I'm considering sponsoring this project, but funding targets on your page list only httpie

[KrisLau]

Also, I'm considering sponsoring this project, but funding targets on your page list only httpie

Super late but I think the sponsor button now includes this project I believe

Considering the decrease in the activity of this project, would you be open to inviting additional maintainers?

@jakubroztocil

[davidgoli]

Hi, I haven't had any time to put into this in the past couple of years at all. I got a new job, and my current product doesn't have a need for this library.

In my view, this project is in need of a ground-up rewrite. The "toString" package should never have been included to begin with - it has an entirely different set of concerns/problems from the basic rrule use case, and isn't covered by the RFC. The code is originally based on a port of the Python implementation in dateutil, but since JavaScript is severely impoverished relative to Python when it comes to builtin Date primitives, there are numerous bugs that are intrinsic to the JavaScript implementation. In turn, trying to address those bugs has presented tradeoffs that are suboptimal.

Ideally an implementation should not use JavaScript builtin date/times at all because they are so idiosyncratic (adding timezone support for example is nearly impossible with the funky behavior of builtin Date). A very promising candidate exists in the Temporal API, but that's been moving slowly and isn't ready for prime time yet.

Furthermore, the RFC is extremely complex, with tons of edge cases, and a full implementation on top of a buggy Date primitive is going to be very expensive to build and to maintain. I would say that's the reason why this project has stalled for years and no replacement has emerged. At the end of the day, somebody (probably a large company) is going to need to sponsor a major effort to implement the RFC and maintain it on an ongoing basis.

So it's not only this project that has been stalled; many related attempts have also stalled, and the reform/replacement of JS Date object has as well.

Having said that, I would be happy to endorse adding additional maintainers who have merged some good PRs. On that front, I will have to first review some PRs. Ideally, someone would come along who can be committed to this project for the long haul. Volunteers?

[KrisLau]

I don't have the skills to really be a good maintainer unfortunately as I'm relatively new to JavaScript however I think I might've seen some forks that might help a bit with some of the problems you mentioned. Not 100% sure though:

• wkst serialization issue fix: robinpowered@744053d

• Ideally an implementation should not use JavaScript builtin date/times at all because they are so idiosyncratic (adding timezone support for example is nearly impossible with the funky behavior of builtin Date). A very promising candidate exists in the Temporal API, but that's been moving slowly and isn't ready for prime time yet.

  • https://github.com/aramk/rrule/commits/feature/meteor
  • https://github.com/schoolhub/rrule/commits/master
  • https://github.com/ReallyCare/rrule/commits/master

• Pull requests wise I tried looking through some to try and help with sorting through and it seems like these ones seem pretty popular:

  • Add support for DTEND, data types, and zoneless local date and date-time values #421
  • Add isFinite, first & last to rrule & rruleset #422
  • Display minutes for time #388

• This one fixes a fatal error: fix: infinite loops in iter when interval is undefined #494

Might also be good to maybe pin this post or a new post to see if that helps with finding more maintainers?

[KrisLau]

@davidgoli Could you add this badge to the package? I submitted a PR to pickhardt/maintainers-wanted#56 to try and help get more maintainers