1

The Year 2038 problem (also called Y2038 or Unix Y2K) relates to representing time in many digital systems as the number of seconds passed since 00:00:00 UTC on 1 January 1970 and storing it as a signed 32-bit integer. Such implementations cannot encode times after 03:14:07 UTC on 19 January 2038. Just like the Y2K problem, the Year 2038 problem is caused by insufficient capacity of the chosen data type.

(source Wikipedia)

I tried to search how this affect Android and its applications. But I didn´t find any clear answer about this. Therefore I would like to ask here:

Can we expect any problems in future (in 2038 and later), if our programs will use System.currentTimeMillis() method?

Are they any dangerous method we should avoid?

Michalsx
  • 3,446
  • 5
  • 33
  • 46
  • 3
    It uses the operating system's clock, so mostly depends on the operating system. Consider it returs a `long`, so it should be able to go well beyond 2038 – Federico klez Culloca Jan 23 '20 at 10:53
  • 2
    Yes. As you can see in [the documentation](https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/lang/System.html#currentTimeMillis()), it returns a `long`, not an `int`. The 2038 problem relates to 32-bit signed integers measuring time in seconds. `currentTimeMillis` uses a 64-bit signed integer measuring time in milliseconds. Unless the underlying source of information is invalid, the Java part of this isn't a problem. – T.J. Crowder Jan 23 '20 at 10:54

1 Answers1

10

System.currentTimeMillis() returns a long, a 64 bit integer, so you'll be safe until the year 292278994.

Luckily, we'll all be dead by then.

Michael
  • 41,989
  • 11
  • 82
  • 128