-
Notifications
You must be signed in to change notification settings - Fork 5
time.Date normalization #3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
scafoglieri
wants to merge
170
commits into
fxtlabs:master
Choose a base branch
from
rickb777:master
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains hidden or 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
… e.g. "1st", "2nd", "3rd", "4th". This can be translated to other locales.
…n strings more efficiently
…on and DurationIn.
…uration. New Days type.
…ally int32) instead of a struct. This makes iterating over a date range easier.
… a regular expression.
…nsequence. Some bugs fixed relating to Last() and End() (formerly called End() and Next()).
…al and economical space for the anticipated usage. Added interfacing to time.Duration and time.Time.
Signed-off-by: Tamal Saha <tamal@appscode.com>
Add flag methods to Period
…e exactly matches that expected
…alue exactly matches that expected
…n be represented as a blank string and the tag 'omitempty' can now work.
…string, which might raise difficulties are the receiver. Code that relied on this incorrect behaviour might see this as a breaking change.
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.
Hi,
the Go function time.Date() have the normalization feature "built-in", so with incorrect input (like 31/04/2018 or 32/02/2018) we get a date, but not the expected one. Since the time.Date() function does not return any error, this behaviour can be acceptable. But in your library (https://github.com/rickb777/date) the ParseISO() function return an error and so I prefer to get just an error instead of a wrong (but well formatted) result with the previous inputs.
So, just in case this is useful even to others, we can get an error in ParseISO() adding (in file parse.go line 149):
Thanks
Michele