Including morning after the time number overrides to 8am.

Examples: date("tomorrow morning") // tomorrow morning at 8am correct-ish date("tomorrow morning at 9") // tomorrow morning at 9am correct date("tomorrow at 9 in the morning") // tomorrow morning at 8am wrong

This fixes issues #70 , #62 , #21

I've removed all lodash dependencies, and wrote my own under subdash.

Also I've finished the CFG implementation, which I call the Human Language for Time. I plan to attach the mathematical proof on the arithmetics and theories behind it soon.

This PR doesn't fix as many problems since there's still several small but pesky issues to resolve, which basically are the inconsistencies between my CFG and the original datejs.

For example, 'tomorrow' will be treated as the next day, defaulted to 9am. Also, I have to implement leap year, and proper carries for days across different months, as they have different number of days.

That's it for now!

This is first of the series of coming NLP-based improvements. This implements a basic normalization module to process string tokens, and map them onto canonical words aka 'lemma', before parsing.

I've added lodash as a requirement. You may wish to add it when publishing the demo site too. There's a list of Issues under work to keep track of next issues to fix. You may wish to update the changelog beneath after approving pr.

Issues fixed: #66, #64, #28, #16, #15, #11, #4

A nicer package manager: http://spmjs.io Documentation: http://spmjs.io/documentation

http://spmjs.io/package/date

It is a package manager based on Sea.js which is a popular module loader in China.

spmjs focus in browser side. We supply a complete lifecycle managment of package by using spm.

If you need ownership of date in spmjs, I can add it for your account after signing in http://spmjs.io.

When using https://github.com/matthewmueller/date/blob/master/dist/date.js directly in the browser I get the following error:

date.js:18 Uncaught Error: Failed to require "./norm" from "date/lib/parser.js"
    at require (date.js:18)
    at localRequire (date.js:171)
    at date.min.js:980
    at require (date.js:35)
    at localRequire (date.js:171)
    at date.min.js:707
    at require (date.js:35)
    at date.min.js:1633
    at date.min.js:1634

That file at the previous commit sha (https://github.com/matthewmueller/date/blob/8fe7afbfb20d72e36f0a7864bd71bd1598401880/dist/date.js) does not have the error and works fine in the browser.

Since LTS has finished for node versions older than 4 there's not really any point in still supporting them and one of the mocha deps doesn't work with older versions of node as it uses const in strict mode.

For example the last build.

/home/travis/build/matthewmueller/date/node_modules/mocha/node_modules/supports-color/index.js:2
const os = require('os');
^^^^^
SyntaxError: Use of const in strict mode.
    at exports.runInThisContext (vm.js:73:16)
    at Module._compile (module.js:443:25)
    at Object.Module._extensions..js (module.js:478:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Module.require (module.js:365:17)
    at require (module.js:384:17)
    at Object.<anonymous> (/home/travis/build/matthewmueller/date/node_modules/mocha/lib/reporters/base.js:11:46)
    at Module._compile (module.js:460:26)
    at Object.Module._extensions..js (module.js:478:10)
make: *** [test] Error 1

Hi Matthew

I made this improvement because that way it seems to make more sense to me.

• Unparsable strings return the current date instead of tomorrow.
• Better prediction if parsed date is close to now (same minute). If it's 10:24 and the string to parse is "10:24", the result will be the current date, not tomorrow.

Great work by the way!

PS: My changes are only on one line, the rest is the result of running make dist && make dist-minify against current master. Tests pass. I'll dive into the i18n subject soon.

Unfortunately including some of lodash's iterators makes the build size jump up. The base-iterator (which is what most these methods depend on) is 52kb unminified.

Not a huge deal since it's still relatively small, but I don't like when a dependency that doesn't do all that much has a larger weight than the library itself ;-).

This is an effort to remove lodash from the build. Most were easily converted to ES5 and below functions, but the remaining are a little trickier:

• [ ] findKey
• [ ] partition

/cc @kengz

Context: When trying to parse a future date with a month, like today is "20th of November" and the future date being parsed is "9th of December". The returned date from date.js would be off by one, i.e. a Date object for the 8th of December.

Solution: I added a test for '9th of December 4:00am' and got the same bug I was running into in my own app. To fix this issue, I modified parser.nextTime to look for a match with the rMonths regex and not add a day to the date.

I hope this makes sense. I appreciate all the work that went into making this awesome library. Thanks for considering this PR.

I feel they're might be a better way of doing this. Something like to peek back one token when we find a numner see if the previous token is the string at.

This is sort of similar to issue 23.

nth = first, second, third, fourth, last day = (mon)day, (tue)sday, (wed)nesday, (thu)rsday, (fri)day, (sat)urday, (sun)day

It would be nice if there was TypeScript support for this library because a lot of project use TypeScript as their main language, and in some of those project, they depend on date.js for things like date time displaying and such. So I would really like to see this library getting add to DefinitelyTyped

The official package on npm is https://www.npmjs.com/package/date.js, on 0.3.3

The unofficial package on npm is https://www.npmjs.com/package/@akepinski/date.js but that has version 4.0.0 - I can see from [History.md] that 0.3.3 was the last release.

Does a version 4.0.0 exist? If not it would be worth taking down the https://www.npmjs.com/package/@akepinski/date.js.

This is such a basic piece of functionality and it makes this package unusable in cases where input must be validated. So what is the thinking here and why has date.js been created in a way that faulty input like this:

date("blah")

actually returns a valid date?

In use cases where an end user is trying to run a search for a time/date range it isn't desired to have every failed parsing default to now/today.

So why is it built this way and why is there no configuration option to turn that off? If a bad date string is provided I wouldn't personally want any value returned.

It's very easy for consumers of date.js to do this if they always want a date value:

function parseDate(val) {
  return date(val) || date("now")
}

But there isn't a way for us to ensure that invalid date values are rejected.

Can this be fixed?