log/slog: slog.Time, doesn't handle dates after year 2262

[mvrhov]

Go version

1.21, 1.22

Output of go env in your module/workspace:

/

What did you do?

package main

import (
	"log/slog"
	"os"
	"time"
)

func main() {
	logger := slog.New(slog.NewJSONHandler(os.Stdout, nil))
	logger.Info("time test", slog.Time("expires_at", time.Date(2300, 1, 1, 0, 0, 0, 0, time.UTC)))
}

This is due to converting time.Time to nanosecond in slog.Time

What did you see happen?

{"time":"2009-11-10T23:00:00Z","level":"INFO","msg":"time test","expires_at":"1715-06-13T00:25:26.290448384Z"}

What did you expect to see?

I expected to see date in future e.g 2300-01-01 00:00:00.0Z in this case

[panjf2000]

Please check out 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).

[mvrhov]

Can I have an explanation on why this was closed. This is a legit bug report. I know that this is because of the use of time.UnixNano, and I have also written this into the original ticket. This is due to converting time.Time to nanosecond in slog.Time
IMHO this should be reopened and the slog must log any valid date time.Time supports. Unless you are saying that's OK, to have weird dates in the log, when you use dates after a certain one.

[seankhliao]

sorry, it was a misclick

cc @jba

[bcmills]

slog must log any valid date time.Time supports.

Unfortunately “any valid date time.Time supports” is currently ill-defined. See:

• time: Integer overflow in Date #56909
• time: unchecked overflow in Add and AddDays #20678

[seankhliao]

also #63844

[mvrhov]

Unfortunately “any valid date time.Time supports” is currently ill-defined. See:

int16 for a year would probably suffice, like in the ticket mentioned by @seankhliao :), but now I'm off-topic.

[jba]

I'm happy to leave this open, but as pointed out here, it is just another consequence of what #63844 is trying to fix. So I don't think there is any action to take now.

[seankhliao]

maybe we can just document the more limited range here?

[panjf2000]

maybe we can just document the more limited range here?

That seems to be the only thing we can do so far.