-
Notifications
You must be signed in to change notification settings - Fork 493
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
Fix issue graphql.Time unmarshal time check #432 #438
Conversation
In case of large unix nanosecond timestamp split them to second and nanosecond part
time check for unix nanoseconds
Can you, please, add unit tests and I'd be happy to merge this PR. Feel free to create a |
add unit tests for time functions
Of course, I added a couple of tests, the coverage of time_test.go should be 100% now. |
time_test.go
Outdated
time.Now().Unix(), | ||
time.Now().UnixNano(), | ||
float64(-1), | ||
"2006-01-02T15:04:05Z", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you, pelase, check the expected values too? So that each test has got
, want
pair. This way you will not only check that marshalling and unmarshalling work but also that they return what you expect.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I wouldn't use time.Now()
instead I prefer constants, please
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now I added the checks for expeced values with assertion library and remove time.Now() usage.
Can you please check if it is ok for you, Thx!
@panikgaul could you, please, check the results too in the tests? |
using fixed date and check the expected values
@panikgaul I'm ready to merge this PR, but I don't want |
@panikgaul are your intentions to remove testify and continue working on this PR? |
#486 solves this problem. Thank you |
Now we can use both unix timestamps: