Решение 2038 года для встроенного Linux (32 бит)?

Каков правильный способ обработки времени в C-коде для 32-разрядной встроенной Linux (ARMLinux), чтобы гарантировать, что код продолжает работать должным образом после 03:14:07 UTC 19 января 2038 года (когда подписанный 32-разрядный time_t переполнения)? Учитывая, что time_t подписали 32-битную систему, которую я должен использовать, каковы альтернативы?

Значительное количество поисковых систем не раскрывает ничего практического использования. Кажется, все полагают, что к этому времени мы все будем использовать 64-битные ОС, но это явно не относится к встроенным системам.

В системе, которую я должен использовать, __kernel_time_t определяется как long. Что, предположительно, означает, что нет ядра для 64-битного времени. Версия uClibc равна 0.9.29.

Не могу поверить, что я единственный с этой проблемой, и я не хочу изобретать велосипед.

Ответ 1

Нет никаких серебряных пуль, трюков или умных решений. Либо используйте операционную систему с 64-битным time_t, либо не используйте time_t и любые объекты ОС, которые зависят от нее (включая файловые системы, таймеры, половину сети и т.д.) Или планируют обновить программное обеспечение в следующем 20 лет.

На 32-битных машинах есть как минимум две unix-подобные системы с 64-разрядным time_t: OpenBSD и NetBSD. В OpenBSD было несколько разговоров, объясняющих причины этого: http://www.openbsd.org/papers/eurobsdcon_2013_time_t/index.html

Ответ 2

Процедуры преобразования времени "просто" должны использовать 2038-01-19: 03: 14: 07Z в качестве основы для времени Unix Epoch, если метка времени меньше определенного значения.

т.е. если ваша система будет работать в 2010-01-01, вы можете предположить, что временная метка, которая не переполнена, ниже 1262300400 (что является временем эпохи unix для этой даты).

Если обнаружена более низкая временная метка, подумайте, что она переполнена и использует 2038-01-19: 03: 14: 07Z в качестве базового времени. Следует также учитывать сравнения.

Не чистое решение, но выполнимое с умеренными усилиями. Лучше переключитесь на 64-битные временные метки (что совсем не обязательно требует 64-битной системы, кстати).

Ответ 3

Я предполагаю, что ваша встроенная система ABI определяет long как 32 бита.

Нет необходимости подписывать тип time_t. Не могли бы вы сделать это unsigned long и купить себе и своим потомкам дополнительные 68 лет спокойствия? Для этого потребуется перекомпилировать ядро, библиотеку C и все программы и библиотеки, которые используют time_t... не для слабонервных! Вы могли бы также определить его как long long, но это изменило бы многие структурные макеты и еще более сложным.