Java переживёт 2038-й. А твой API?
Сегодня в канале Хабра попалась статья про Unix-время. Хороший повод проверить, где в приложении заканчивается long.
В Java Instant.getEpochSecond() возвращает long. Дата после границы 2038 года помещается спокойно. Но дальше timestamp нужно передать в API, а в DTO кто-то когда-то написал int.
Минимальный пример:
long seconds = Instant.parse("2038-01-19T03:14:08Z") .getEpochSecond();
int apiTimestamp = (int) seconds;
System.out.println(seconds); System.out.println(apiTimestamp); System.out.println(Instant.ofEpochSecond(apiTimestamp));
Получаем:
2147483648 -2147483648 1901-12-13T20:45:52Z
Одно приведение типа — и вместо января 2038-го приехали в декабрь 1901-го. Без исключения.
Поэтому проверять нужно весь путь значения: поле DTO, контракт API, колонку БД, формат сообщения. Одного long внутри приложения недостаточно.
Если по контракту нужен именно int, хотя бы проверяем диапазон:
int apiTimestamp = Math.toIntExact(seconds);
Теперь получим ArithmeticException, а не тихо испорченную дату. Но для поддержки дат за этой границей придётся менять сам контракт. Документация Java.
И ждать 2038 года необязательно. Даты окончания подписок, договоров и долгосрочных расписаний можно проверить уже сейчас.
