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.

[rsc]

This issue is about slog happening to have picked a very tiny time format compared to time.Time in its zeal for avoiding allocations. This has nothing to do with #63844, which is about optimizing the time package. It's true that the issue suggests restricting the time range, but to something like 60,000 years, not the mere 500 that slog allows.

I think we should probably fix this by making the time constructor store an actual time.Time into v.any when the value is out of range for UnixNano. That would still be allocation-free for all the times anyone would ever see, but it also avoids slog introducing time range restrictions that do not exist in package time.

/cc @jba

[gopherbot]

Change https://go.dev/cl/585519 mentions this issue: log/slog: handle times with undefined UnixNanos