apache/dubbo-go-hessian2

时间encode越界

Penglq opened this issue · 7 comments

Penglq commented

What happened:
dubbo-go一个原始日期为：2296-11-23 16:09:26.311 的值，java那边收到的是另一个值，是因为hessian的类型不对导致越界了吗
What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Penglq commented

是time.UnixNano int64类型越界，如果使用time；当时开发的时候go版本不高，在encode为ms时间戳时，只有time.Unix和UnixNano，Unix()会丢失ms精度，能支持到2262年，所以用的UnixNano()/1e6。

可以先看看业务上是不是可以把这个值缩小，如果是过期时间/封禁时间的话 可以考虑一下

tiltwind commented

@Penglq can u submit a unit test to simulate the unexpected case, ref

dubbo-go-hessian2/date_test.go

Line 96 in 4820c03

testJavaDecode(t, "argDate_0", time.Date(1970, 1, 1, 0, 0, 0, 0, time.UTC))

tiltwind commented

@Penglq the hessian2 uses the api time.UnixNano(), but the year 2914 overflows for int64 for nanoseconds.
From golang 1.17, it supports time.UnixMilli() api, which will fix this issue. (see golang/go#44196)

But now the go version of the hessian ci used is 1.13, maybe we needs to upgrade the go version now.
How do u think？@AlexStocks

// UnixNano returns t as a Unix time, the number of nanoseconds elapsed
// since January 1, 1970 UTC. 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). Note that this means the result of calling UnixNano
// on the zero Time is undefined. The result does not depend on the
// location associated with t.
func (t Time) UnixNano() int64 {
	return (t.unixSec())*1e9 + int64(t.nsec())
}
ilaotan commented

支持升版本