VIP Expiration Timestamp Overflow Bug Caused by MySQL INT Limit (Year 2038 Problem)

There is a type of bug that does not affect functionality directly and users will not encounter it during normal usage, but some test cases still cover it; often it is left unfixed because it has no user impact.

The bug shared here is that a user's VIP expiration date can only be set up to a certain day in 2038.

The scenario occurs when a user continuously purchases VIP subscriptions and eventually a purchase fails in the year 2038.

Business logic: when a user buys a one‑month VIP, the VIP expiration is extended by 30 days. If the user was not previously a VIP, the current timestamp is extended by 30 days and a fee is charged.

To verify transaction risk control limits and the stability of the entire VIP purchase flow, a test case was written that loops continuously purchasing VIP.

The database schema is simple: each user (if present) has a single record storing the VIP status, mainly the VIP expiration timestamp and some other fields. Purchase and transaction records are stored in separate tables and are unrelated to this bug.

Root cause: the expiration timestamp is stored using an int type; MySQL signed INT can hold a maximum value of 2,147,483,647, which corresponds to 2038‑01‑19 11:14:07 (Beijing time). When the timestamp reaches this limit, it can no longer store a correct future date.

Solution: treat the problem as non‑existent.

Although the bug was discovered unintentionally and remains unfixed, it is still considered an interesting case.