64bit time_t in Linux Kernel
 

I have compiled kernel 3.19.1 but still have a problem with time_t. Just simple program with cout << sizeof (time_t); gives size of 4 bytes, not 8 bytes as was my intention. Should I switch on a particular option during make menuconfig?

Weird.

My code (some garbage around):
Compilation:
g++ test.cpp -o test

Result:
8

You're sure that you're using a 64bit OS?
What's the output of "uname -a"?

Yes, that is true. I have tested it with 32bit Linux and 32bit CPU.
Is it possible to patch the kernel and have long and time_t types with size of 8 bytes on 32bit CPU?
Maybe '64-bit kernel' option during make menuconfig should solve that issue?

Why would changing the kernel affect a user-space program? Are you specifying -m32 or -m64?

I'm probably typing out of turn as I'm out of my depth here but a memory of trying to learn C and a google makes me think that time_t will be defined in the C libraries you link to so is that clib[or whatever]?
Please ignore, and sorry, if I am obviously ignorant.

What does code for a system-on-chip FPGA have to do with this discussion?

Not the kernel, but the architecture? My understanding is that on a 64 bit system, time_t is defined as 64 bits; on a 32 bit system it is 32 bits. That is how I read <bits/types.h> and <bits/typesizes.h>, but I could be wrong.

From another point of view, I've always read that the solution to the Unix/Linux "year 2037 problem" when the old time_t wraps around is the 64 bit architecture which has a bigger time_t.

Maybe there is a workaround, depending on what you want want to do / what the reason is for you to get time_t as 64bit or bigger.

I have decided to use boost:: posix_time:: ptime instead of time_t and related functions like mktime().

Thx - and I agree, most probably the best alternative.

Well, it is indeed a good alternative. Right now I have to make some software for x86 embedded platform which is of course 32bit architecture. It's only a little chance it will still run on 2038, but who knows... better to be prepared :)

Kernel defines what time_t is, standard C library just obeys, because it has no other choice.

You cannot patch a kernel to change time_t to 64-bit on x86 because that would change the ABI of a time syscall and in turn all of your user-space. To make that work youd have to rebuild your whole system starting from C library. And of course hunt all the bugs in applications where author assumed sizeof(time_t) == sizeof(long) or something similar.

Using Boost (or anything else) does not solve the problem of system time wrapping around 2038 on 32-bit systems.

PS. This might be a better fit for Programming forum.

Boost does not affect the system date and time_t of course, but solves the y2038 problem in my piece of code. That's enough for me.
In case of system time maybe here's a little hope:
http://lwn.net/Articles/607741/