Skip to content
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

Incorrect time value with zap.Time() when using a time far in the future #803

Closed
gkotian opened this issue Mar 21, 2020 · 2 comments
Closed

Comments

@gkotian
Copy link

gkotian commented Mar 21, 2020

I'm trying to log a time value that is set to something very far in the future. It is supposedly the largest time value possible according to https://stackoverflow.com/a/25065327/793930.

I'm using the plain Logger, and creating the field for the log message using zap.Time().
https://play.golang.org/p/Nc8jv_8NkCs

If you run the code in the playground, you'll see that t1 is the same in both the zap log and in the fmt.Println print. However, t2 is reported incorrectly in the zap log as:

1754-08-30T22:43:41.128Z
@prashantv
Copy link
Collaborator

This is similar to #737

I think we should do the same fix as suggested there: if a value is out-of-range for UnixNano, then store a different representation internally.

prashantv added a commit that referenced this issue Mar 24, 2020
Fixes #737, #803.

Time values are encoded by storing the UnixNano representation, but this
fails when the value of UnixNano is out of int64 range, see docs:

https://golang.org/pkg/time/#Time.UnixNano
> The result is undefined if the Unix time in nanoseconds cannot be
represented by an int64 (a date before the year 1678 or after 2262)

Fix this by storing values outside of UnixNano range as-is rather
than using UnixNano with a new Field type.
prashantv added a commit that referenced this issue Mar 27, 2020
Fixes #737, #803.

Time values are encoded by storing the UnixNano representation, but this
fails when the value of UnixNano is out of int64 range, see docs:

https://golang.org/pkg/time/#Time.UnixNano
> The result is undefined if the Unix time in nanoseconds cannot be
represented by an int64 (a date before the year 1678 or after 2262)

Fix this by storing values outside of UnixNano range as-is rather
than using UnixNano with a new Field type.
@abhinav
Copy link
Collaborator

abhinav commented Apr 30, 2020

Resolved in #804

@abhinav abhinav closed this as completed Apr 30, 2020
uvfive pushed a commit to bxsmart/zap that referenced this issue May 21, 2020
Fixes uber-go#737, uber-go#803.

Time values are encoded by storing the UnixNano representation, but this
fails when the value of UnixNano is out of int64 range, see docs:

https://golang.org/pkg/time/#Time.UnixNano
> The result is undefined if the Unix time in nanoseconds cannot be
represented by an int64 (a date before the year 1678 or after 2262)

Fix this by storing values outside of UnixNano range as-is rather
than using UnixNano with a new Field type.
cgxxv pushed a commit to cgxxv/zap that referenced this issue Mar 25, 2022
Fixes uber-go#737, uber-go#803.

Time values are encoded by storing the UnixNano representation, but this
fails when the value of UnixNano is out of int64 range, see docs:

https://golang.org/pkg/time/#Time.UnixNano
> The result is undefined if the Unix time in nanoseconds cannot be
represented by an int64 (a date before the year 1678 or after 2262)

Fix this by storing values outside of UnixNano range as-is rather
than using UnixNano with a new Field type.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants