Open davidkaneda opened 11 years ago
Yah, I think you're right, this month, this year are too vague (on their own). We do not want to it to break for things like next month this year
though.
This library shouldn't directly support but facilitate iterative timespans in other libraries because there's great value in allowing that. The original intent of this library was to support iterative timespans, but found it was better to separate it out. I built every for that purpose.
Also +1 on ignoring spans of times.
This is a bit of a subjective patch: It changes the behavior so that unmatched entries return null.
Previously, there was code that looked to throw an error in this situation, though the code wasn't constructed right and would never throw. When implemented properly, the code errors on "this year" and "this month" as they both fulfill the "error" requirement of Date.js output matching "now."
I think it would be good if we always expect something consistent out of date.js — which I believe is a specific time & date based off the input. ie, the library should support:
But it should not support:
Just a thought, discussion welcome :)