[question] Can I tell Chronic to only parse a date if it contains a day, month and year?

[sphanley]

For example, if I am trying to parse a natural language representation of a date of birth -- if only a month and year is present, that date could still be parsed, but it would be invalid for my use case. Is there a way to tell the parser to enforce requiring specific date components?

[davispuh]

Currently it's not possible, but in my rewrite branch it would be very simple to implement it.

[sphanley]

Thanks for the info! Can you help me understand the roadmap for the rewrite? It seems like it's been in the works for a very long time - is there a release planned, or is it still an ongoing effort currently? Are you the primary maintainer of the Chronic project at this point?

The reason that I ask is that there's a C# port of Chronic that hasn't been updated in quite some time, and I'm potentially interested in forking and updating it to include the improvements from your rewrite, but I wanted to understand how far along your project is to determine whether it makes sense to undertake that porting work at present.

[davispuh]

I would say currently there isn't really any maintainer since I just happened to work on this but I wouldn't call myself as a real maintainer. I just want to fix some bugs and add support for features I need :D . Anyway I do have git commit access but no access to rubygems so I can't release new gem. But when I'll be done I'll merge my branch in master and contact @leejarvis on Twitter to get new gem out, but before merge release a new version and then one after.

About my rewrite branch progress you can read my comment on #344 . I would say it's pretty much all done and there won't be any big changes. Only thing that's left to do is timezone name parsing. For that currently I've been working on rewriting my TimezoneParser gem to improve performance (switch from Marshal to SQLite) which is used in my rewrite branch. Then once that is done I'll probably go over all GitHub issues and fix them and make a release. But when this will happen it's hard to say as I'm doing this in my free time and not that often.

About that C# port, I had never seen it before but I think it really wasn't good idea to make direct port but way better would have been take this code as inspiration and as an example but create it from scratch based on these ideas. I don't really know what would be best way to update and port it, like my rewrite changes a lot of things, I would recommend you to take a look at code and see yourself #347

[sphanley]

Sounds good - I'm going to work on familiarizing myself with the code a bit, and see what seems like the best option in terms of advancing a C# version. Thanks for the background!

I agree that a direct port is probably not the most maintainable course of action - the port only came to my attention because I discovered that it's used (via a NuGet package) in Microsoft's Bot Builder SDK, which is a pretty major project - it's mostly used in their sample projects, but it's used in at least one place in the framework itself. It definitely seems odd to me that they've got a dependency on a seemingly discontinued cross-language port. I'd love to see a more robust C# option that can be maintained going forward!