When VIP Expiration Hits 2038: Uncovering MySQL INT Overflow

A non‑functional bug was found in a VIP subscription system: after repeatedly purchasing monthly VIP extensions, the stored expiration date could not go beyond a certain day in 2038.

The test scenario involved a loop that continuously bought VIP months to verify risk‑control limits and overall process stability. Each user has a simple record storing the VIP expiration timestamp; other tables hold purchase and transaction logs, which are unrelated to the bug.

The root cause is the use of a signed INT column in MySQL to store the Unix timestamp. The maximum signed INT value is 2,147,483,647, which translates to 2038‑01‑19 11:14:07 (Beijing time). When the calculated expiration exceeds this value, MySQL cannot store the correct timestamp, leading to failure.

The pragmatic “solution” adopted was to ignore the issue, as it does not affect current users; however, the anecdote highlights the importance of choosing appropriate data types for future‑proof time handling.