Функция Даты/времени работающая после 38-го года.

А какие функции фигню кажут?

Которые работают с POSIX таймстампом.

date --date='@9000000000'
Ср мар 14 20:00:00 MSK 2255

и?

GetLocalTime, GetSystemTimе

может стоило язык выбрать?

Или вот так:

date +%s --date='20:00 01 may 3666'
53531078400

Кроссплатформенные.

Которые работают с POSIX таймстампом.

Он 4 байта, а 4 байта заканчиваются после 38-го

sizeof(time_t) == 4

Которые работают с POSIX таймстампом.

Нет никакой причины, по которой POSIX timestamp не может работать после 2038 года. Это количество секунд от определённого события. Что с ним будет после 2038 года?

Вот что оно не влезет в 32 бита после 2038 года — это правда. Но, во-первых, к тому моменту 64-битные системы будут, наверное, даже в наручных часах, а во-вторых, новые языки программирования и платформы даже на 32-битных осях используют представление времени, которое продолжит работать и после 38-го года, если только от системы такое время удастся получить.

Типа, чтобы на 32-битном недоразумении тоже работали?

Дык, будут, если ты правильно объявишь тип переменной, а не будешь фигней с интами маяться!

может стоило язык выбрать?

А что, есть что-то кроме C/C++ ?

Очень сильно сомневаюсь, что функции могут работать и с time_t и с длинным вариантом.

Все POSIX функции (и не только) вполне работают. Главное, чтобы time_t был хотя бы 64битный.

Что с ним будет после 2038 года?

Он превратится в 1970-й

Они будут работать, если будешь все правильно делать.

Эту проблему уже, наверное, лет 10 как решили! Так что обнови свой древний glibc!

Ок, ну раз вы так все настаиваете что оно будет работать, то...

Всем спасибо.

sizeof(time_t) == 4

Это неверно! Бабам задниц резать не будут:

--> cat timec.c
#include <stdio.h>
#include <time.h>

int main(int argc, char **argv) {
	printf("%lu\n", sizeof(time_t));
}
--> gcc timec.c
--> ./a.out    
8

У меня четверка вылазит.

Размер time_t - на совести системной libc, насколько я помню.

А в OpenBSD эту проблему в последнем релизе решили, главная фича была :)

Типа, чтобы на 32-битном недоразумении тоже работали?

А вы, случайно, не принц?

У тебя glibc 2001-го года выпуска что ли?

а что за принц, у них у всех бзик на царскую тематику?

Что с ним будет после 2038 года?

Он превратится в 1970-й

В 1970 он привратился бы году эдак в 2106. Учи матчасть.

У меня четверка вылазит.

не ври :)

А вы, случайно, не принц?

Нет, это у нас митрополит всея Си.

Википедия говорит, что the consensus is for time_t to be signed, and this is the usual practice, то есть не 2**32-1, а 2**31-1.

На 32-битных линуксах размер time_t равен 4. Проверил только что на свежей 32-битной убунте.

Ничего, к 2038 году 32-битных уже точно не будет.

Но в любом случае, кто ищет, тот всегда найдет, как избавиться от идиотизма с 32-битным time_t!

Он 4 байта, а 4 байта заканчиваются после 38-го

vault ~> cat ts.c        
#include <stdio.h>
#include <time.h>

int main()
{
        printf("%lu\n", sizeof(time_t));
        return 0;
}
vault ~> clang ts.c -o ts
vault ~> ./ts
8
vault ~> uname -a
OpenBSD vault 5.5 GENERIC.MP#315 amd64

Используй правильные операционные системы.

ок, теперь запусти это на правильной ОС

Еще раз повторяю!

Для любителей 32-битной архитектуры тоже есть решение!

Для любителей 32-битной архитектуры тоже есть решение!

Для любителей 32-битной архитектуры лучшим решением будет закопаться.

Шел 2038 год. Народ продолжал сидеть на патченой-перепатченой 32-битной Windows XP.

А как ты предлагаешь поставить 64-битное ведро на 32-битное железо? А такого, между прочим, еще дохренища!

К 2038 году его вряд ли будет достаточное количество для того, чтобы беспокоиться об этом.

Звучит расточительно, но правда.

Возможно. Сейчас уже даже микроконтроллеры как-то все ближе и ближе к 64 битам подбираются.

А как ты предлагаешь поставить 64-битное ведро на 32-битное железо?

Зачем? Можно просто дропнуть старый ABI и сделать time_t 8-байтовым. В OpenBSD 5.5, например, так и сделали. На всех платформах сразу, даже на 32-битных.

пусть openbsd ставят, там даже в 32 битной всё работает