This is an issue when a smaller integer type value is widened to a larger integer type and then used as an absolute timestamp, such as milliseconds or seconds since the Unix epoch (January 1, 1970).

Why is this an issue?

A 32-bit signed integer can hold values from -2,147,483,648 to 2,147,483,647. While this might seem like a large range, it’s insufficient for representing timestamps:

• Milliseconds since epoch: A 32-bit integer can only represent approximately 24.8 days of milliseconds. Any timestamp beyond this range will overflow.
• Seconds since epoch: A 32-bit integer can represent about 68 years, covering dates from 1970 to 2038. This is the famous "Year 2038 problem" for 32-bit systems.

When you cast a 32-bit integer to a 64-bit integer for use as a timestamp, you’re not fixing the underlying problem — the value is already corrupted or limited by the 32-bit constraint before the cast happens. The cast simply preserves the incorrect or overflowed value in a larger container.

Timestamps should be stored as 64-bit integer values from the start to ensure they can represent dates far into the past and future without overflow. A 64-bit integer type can represent timestamps for approximately 292 million years, which is more than sufficient for any practical application.

Using a 32-bit integer for timestamps is almost always a bug that will cause:

• Incorrect date and time calculations
• Application failures when processing dates outside the limited range
• Data corruption when timestamps overflow
• Difficult-to-diagnose issues in production systems

In Java, 32-bit integers are represented by the int type and 64-bit integers by the long type.

What is the potential impact?

Using 32-bit signed integer types for timestamps can lead to serious reliability issues:

• Incorrect time representation: Dates may be displayed incorrectly or calculations may produce wrong results
• System failures: Applications may crash or behave unpredictably when timestamps overflow
• Data integrity issues: Stored timestamps may be corrupted, leading to incorrect historical records
• Year 2038 problem: For second-based timestamps, the system will fail on January 19, 2038, when the maximum value representable by a 32-bit signed integer is exceeded

How to fix it

Change the variable type from int to long to properly represent the timestamp. This ensures the value can hold the full range of possible timestamp values without overflow.

Code examples

Noncompliant code example

int timestamp = 1234567890;
Date date = new Date(timestamp);          // Noncompliant: int implicitly widened
Date date2 = new Date((long) timestamp);  // Noncompliant: the cast does not fix the overflow

Compliant solution

long timestamp = 1234567890L;
Date date = new Date(timestamp);

Resources

Documentation

• Java Documentation - Primitive Data Types
• Java Documentation - Class System - currentTimeMillis()
• Java Documentation - Class Instant