Natural Language Hours Parsing

The goal of this challenge is to create a parser that can read store opening hours written by a human and produce a machine-readable structured representation.

For example:

var hours = require('kites-challenge-1')
var input = 'Sun.-Thur. 11:00-23:00, Friday-Sat. 1100-0000'
var output = hours.parse(input)
console.log(output)  // S0-4:1100-2300;5-6:1100-2400

Please also read the FAQ.

The Output Format

The first thing you should do is read test/index.js. It is the canonical reference. As long as your parser correctly implements the reference tests, it is considered a correct solution.

Some English notes:

• There is only one correct output for a given input string.
• The parser deals with overlaps.
• A day begins at 0000 and ends at 2800.

Usage

Instructions

1. Clone this repository to your own Github public repository and development machine. Do NOT fork, as other candidates would be able to see your solution. Do preserve commit history so it is easy for us to add your repository as a remote.
2. Send us a link to the public repository you used and an estimate of how long you will take
3. Run npm install
4. Implement hours.parse in lib/index.js
5. Ensure all tests pass in node via npm test
6. Ensure all tests pass in phantomjs and all browsers
7. When finished, send us an email to ask for a review

Hints

• Before starting, study the input grammar in test/index.js very carefully.
• We deliberately excluded some edge cases to make your implementation easier. You do not need to implement a full-blown solution that will parse every possible way of writing store opening hours; just the ones listed in the test file.
• After writing a correct implementation in English, dealing with Chinese input should be relatively trivial.
• At Kites, we use zuul and SauceLabs to do our browser testing. SauceLabs includes nice free testing support for public repositories.

Scoring

To pass, you must provide supporting proof or very clear instructions for how to build and verify your solution passes tests in node, phantomjs, and all browsers. If your solution fails for any subset of platforms or platform versions (e.g. passes every Firefox except Firefox 24.0), you must document the failure and explain why.

You will be graded on how easy-to-{read,maintain,verify} your code and documentation are. Really think from the perspective of what would happen if we had to actually integrate your code into our production environment.

Ideally your solution is easily extensible as we add additional types of test cases. We strongly encourage you to casually browse the web and research other ways humans write opening hours. A trivial example: how much work would it be to accomodate hours that look like "9:30 a.m. - 5:00 p.m. Mon to Fri"?

Bonus points for including additional (even if .skiped) tests in your solution from this research.