Return null with no matches and nix "this month" and "this year." #14
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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: * "Next tuesday," or "tomorrow" (guessing the time based off of now) * Tomorrow at 3pm * Now (this should probably be added...) * etc. But it should _not_ support: * Every 5 minutes (iterative time increments) * For the next 3 months (span of time) * "This month" and "this year" (vague) Just a thought, discussion welcome :)
| if(!(this instanceof parser)) { | ||
| var parsed = new parser(str, offset); | ||
|
|
||
| if(!(parsed instanceof parser)) { |
There was a problem hiding this comment.
personally, i find this double instanceof logic confusing. is there anything else we can do here to get the same results?
|
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 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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 :)