Andrew Plummer

Hi... apologies for taking ages here... So it seems that all of the formats you're passing here except the last one are falling back to native browser parsing, which does...

Also a reminder to self here that the parsed timezones should be passed into the populated params object so that they can be handed off to a library that does...

Thanks for posting this... I suppose this is a regression so I will mark it as a bug, even though I'm on the fence about whether it's an actually valid...

This one should be considered a bug. `end of the year` returns the correct dates and `end of year` should do the same... will look into this one.

Okay... first of all this is happening because anything that does not match Sugar's internal patterns falls back to native date parsing. I *was* going to go into how native...

Just created #637 and #638 for the issues I mentioned.

Ah one other point I forgot to mention is that this is going to be a bit tricky :) Month parsing is one thing but if we do this I'd...

Actually I take it back... it seems that native JS *can* allow overshooting in parsing... for example: ``` new Date('2/30/2018'); ``` It seems that Chrome and FF only perform a...

Also note that any date format outside ISO8601 is outside the spec, so it's uncharted territory here.

The other question this opens up is should `the 29th` fail because no month/year is passed and it happens to be a non-leap-year February at the moment? In terms of...