Fix for Y2038 problem #15934
Fix for Y2038 problem #15934
Conversation
We expect Knative Serving to run after 2038.
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Fedosin The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
knative-prow
bot
added
the
size/XS
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #15934 +/- ##
==========================================
- Coverage 80.98% 80.94% -0.05%
==========================================
Files 210 210
Lines 16780 16780
==========================================
- Hits 13590 13582 -8
- Misses 2840 2845 +5
- Partials 350 353 +3 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| // NB: we need to divide by granularity, since it's a compressing mapping | ||
| // to buckets. | ||
| return int(tm.Unix()) / int(t.granularity.Seconds()) | ||
| return int(tm.Unix() / int64(t.granularity.Seconds())) |
There was a problem hiding this comment.
Technically golang when compiling apps on 64bit host int64=int so technically this isn't an issue here.
Even with the change if were compiling on a 32bit machine you'd be converting int64 => int32 without any bounds check.
I wonder if 'modulo' is the better operation here or we should just simply fail the build on 32bit systems
We expect Knative Serving to run after 2038.
Release Note