Fix int64 overflow in newNumericDateFromSeconds

[PiotrKozimor]

int64(f*float64(time.Second)) may easily overflow (this bug occured for me when validating token). I suggest here alternative approach to parse NumericDate.

[oxisto]

Looks to be a good alternative.

[PiotrKozimor]

Thanks, can you merge it? I don't have such a possibility.

[oxisto]

Thanks, can you merge it? I don't have such a possibility.

We usually want to have two reviews before we merge it.

cc @mfridman @lggomez

[mfridman]

Are you using 200y tokens, i.e., overflowing sometime in 2200's 😛

Thanks @PiotrKozimor

[tiramiseb]

Hello,

I just debugged the same line locally :-)

However, I think there is no need to extract nanoseconds, because the NewNumericDate function which is called truncates the time... with a TimePrecision of 1 second.

Thus, I was going to create a PR that would simply have the following:

func newNumericDateFromSeconds(f float64) *NumericDate {
	return NewNumericDate(time.Unix(int64(f), 0))
}

[tiramiseb]

Are you using 200y tokens, i.e., overflowing sometime in 2200's 😛

yep, in unit-tests, to be absolutely sure a token would never expire in tests.

I know, it's a bit overkill, but well...

[oxisto]

Hello,

I just debugged the same line locally :-)

However, I think there is no need to extract nanoseconds, because the NewNumericDate function which is called truncates the time... with a TimePrecision of 1 second.

Thus, I was going to create a PR that would simply have the following:

func newNumericDateFromSeconds(f float64) *NumericDate {
	return NewNumericDate(time.Unix(int64(f), 0))
}

You can configure the truncating precision. Default is second but there was a request to support adjusting it. So the original approach in this PR should be ok.

[tiramiseb]

You can configure the truncating precision. Default is second but there was a request to support adjusting it. So the original approach in this PR should be ok.

Thanks! Indeed, if the truncating precision is meant to be modified, my suggestion is not okay 🙂