I am working around a problem called Y2038 bug.
http://groups.google.co.in/group/comp.unix.programmer/browse_thread/t...

I am developing an application which need to be built both on windows
and linux and used time_t, ctime, mktime, localtime and gmtime
functions from <time.h>.

The application already exists and I have to replace these 32bit time
structures with their 64bit equivalents. I have made all the changes
and built the application on windows but can't do so on linux because
Linux does not seem to have a 64 bit equivalent for time_t , or
mktime..

http://msdn2.microsoft.com/en-us/library/bf12f0hc.aspx
Is there a patch or some workaround it? need suggestions
Thank

On Feb 11, 3:30 am, Aditi <drool.g...@gmail.com> wrote:

> The application already exists and I have to replace these 32bit time
> structures with their 64bit equivalents. I have made all the changes
> and built the application on windows but can't do so on linux because
> Linux does not seem to have a 64 bit equivalent for time_t , or
> mktime..

Are you using 32-bit Linux or 64-bit Linux? If your goal is to have
actual compiled code that will run in 2038, you will have to build it
for 64-bit Linux. It is not currently possible to make a 32-bit Linux
kernel or 32-bit Linux applications that will work unmodified after
2038.

$ cat test.c
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int main(void) {
 printf("Sizeof(time_t)==%d\n", sizeof(time_t));
}
$ uname -ri
2.6.23.14-115.fc8 x86_64
$ gcc test.c -o test
$ ./test
Sizeof(time_t)==8

Looks fine to me.

DS

David Schwartz wrote:

> Are you using 32-bit Linux or 64-bit Linux? If your goal is to have
> actual compiled code that will run in 2038, you will have to build it
> for 64-bit Linux.

Sorry, thats wrong. sizeof (time_t) is 8 on 32 and 64 bit Linux.

> #include <stdio.h>
> #include <stdlib.h>
> #include <time.h>
> 
> int main(void) {
>  printf("Sizeof(time_t)==%d\n", sizeof(time_t));
> }
> $ uname -ri
> 2.6.23.14-115.fc8 x86_64
> $ gcc test.c -o test
> $ ./test
> Sizeof(time_t)==8

You get exactly the same result on 32 bit linux.

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"Only wimps use tape backup: *real* men just upload their
important stuff on FTP, and let the rest of the world
mirror it ;)" -- Linus Torvalds

David Schwartz <davids@webmaster.com> writes:
> On Feb 11, 3:30 am, Aditi <drool.g...@gmail.com> wrote:
>> The application already exists and I have to replace these 32bit time
>> structures with their 64bit equivalents. I have made all the changes
>> and built the application on windows but can't do so on linux because
>> Linux does not seem to have a 64 bit equivalent for time_t , or
>> mktime..
>
> Are you using 32-bit Linux or 64-bit Linux? If your goal is to have
> actual compiled code that will run in 2038, you will have to build it
> for 64-bit Linux. It is not currently possible to make a 32-bit Linux
> kernel or 32-bit Linux applications that will work unmodified after
> 2038.
[...]

It's not *currently* possible, but as far as I know there's no
fundamental reason why 32-bit Linux couldn't be changed to use a
64-bit time_t (it would be a typedef for unsigned long long).  Of
course that doesn't do the original poster any good.

On the other hand, it's certainly possible to implement your own
64-bit time type and a mktime-like function that uses it, but it won't
play well with the underlying system.

-- 
Keith Thompson (The_Other_Keith) <kst-u@mib.org>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Erik de Castro Lopo wrote:
> David Schwartz wrote:
> 
>> Are you using 32-bit Linux or 64-bit Linux? If your goal is to have
>> actual compiled code that will run in 2038, you will have to build it
>> for 64-bit Linux.
> 
> Sorry, thats wrong. sizeof (time_t) is 8 on 32 and 64 bit Linux.
> 
>> #include <stdio.h>
>> #include <stdlib.h>
>> #include <time.h>
>>
>> int main(void) {
>>  printf("Sizeof(time_t)==%d\n", sizeof(time_t));
>> }
>> $ uname -ri
>> 2.6.23.14-115.fc8 x86_64
>> $ gcc test.c -o test
>> $ ./test
>> Sizeof(time_t)==8
> 
> You get exactly the same result on 32 bit linux.

Well, I'm running a 32bit Linux, and I get different results

  ~/code $ uname -ri
  2.4.33.3 i386

  ~/code $ cat t1.c
  #include <stdio.h>
  #include <stdlib.h>
  #include <time.h>

  int main(void)
  {
    printf("sizeof(time_t) = %d\n",(int)sizeof(time_t));
    return EXIT_SUCCESS;
  }

  ~/code $ gcc -o t1 t1.c

  ~/code $ ./t1
  sizeof(time_t) = 4

  ~/code $


-- 
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/   | GPG public key available by request
----------      Slackware - Because I know what I'm doing.          ------

On Feb 11, 1:54 pm, Keith Thompson <ks...@mib.org> wrote:

> It's not *currently* possible, but as far as I know there's no
> fundamental reason why 32-bit Linux couldn't be changed to use a
> 64-bit time_t (it would be a typedef for unsigned long long).  Of
> course that doesn't do the original poster any good.

> On the other hand, it's certainly possible to implement your own
> 64-bit time type and a mktime-like function that uses it, but it won't
> play well with the underlying system.

You can fix your source code, but you cannot compile it today and have
it work in 2039.

FWIW, the industry consensus is that it is too early to work on the
year 2038 problem. I disagree and have publically argued for a 64-bit
time interface on 32-bit operating systems since at least 2003.

Quoting myself from that time:

"I've proposed both a time64_t solution (with corresponding time64/
mktime64 functions), including a method to cause these types/functions
to replace the defaults. I've also proposed an alternate
assumptionless interface (one where all the time types are opaque
except
structures).

But the world seems to be at an impasse. The opposition to my
suggestions is that any code that is broken by a switch to a 64-bit
time_t is broken already, and that therefore the 'right' solution is
to switch to a 64-bit time_t. The opposition to that suggestion is
that it will cause needless pain and hurt performance. So we're at a
stalemate, waiting for
2038 to get here, while code that needs to manipulate future times has
to be made clumsy and we're writing and compiling code today that we
know we'll have to at least recompile. *sigh*"

DS

David Schwartz <davids@webmaster.com> writes:

>FWIW, the industry consensus is that it is too early to work on the
>year 2038 problem. I disagree and have publically argued for a 64-bit
>time interface on 32-bit operating systems since at least 2003.

I think I agree.

>Quoting myself from that time:

>"I've proposed both a time64_t solution (with corresponding time64/
>mktime64 functions), including a method to cause these types/functions
>to replace the defaults. I've also proposed an alternate
>assumptionless interface (one where all the time types are opaque
>except structures).

>But the world seems to be at an impasse. The opposition to my
>suggestions is that any code that is broken by a switch to a 64-bit
>time_t is broken already, and that therefore the 'right' solution is
>to switch to a 64-bit time_t. The opposition to that suggestion is
>that it will cause needless pain and hurt performance. So we're at a
>stalemate, waiting for
>2038 to get here, while code that needs to manipulate future times has
>to be made clumsy and we're writing and compiling code today that we
>know we'll have to at least recompile. *sigh*"

I don't think it's quite as easy as doing the "64 bit file offsets"
as so many structures in UNIX embed a time_t or some time value someplace.

But if people need to recompile, which they will, why not just recompile
for 64 bits and be done with it?

There's not a lot of impetus to fix 32 bit computing when mainstream
computing is already predominantly 64 bit.

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

David Schwartz <davids@webmaster.com> writes:
>On Feb 11, 1:54 pm, Keith Thompson <ks...@mib.org> wrote:
>
>> It's not *currently* possible, but as far as I know there's no
>> fundamental reason why 32-bit Linux couldn't be changed to use a
>> 64-bit time_t (it would be a typedef for unsigned long long).  Of
>> course that doesn't do the original poster any good.
>
>> On the other hand, it's certainly possible to implement your own
>> 64-bit time type and a mktime-like function that uses it, but it won't
>> play well with the underlying system.
>
>You can fix your source code, but you cannot compile it today and have
>it work in 2039.
>
>FWIW, the industry consensus is that it is too early to work on the
>year 2038 problem. I disagree and have publically argued for a 64-bit
>time interface on 32-bit operating systems since at least 2003.

By 2038 there will be _no_ 32-bit operating systems left outside of
museums.

scott

On Feb 12, 1:06 pm, sc...@slp53.sl.home (Scott Lurndal) wrote:

> By 2038 there will be _no_ 32-bit operating systems left outside of
> museums.

8-bit CPUs were replaced by 16-bit CPUs in 1980 the same way 64-bit
CPUs are now replacing 32-bit CPUs. 28 years later, more than 20
manufacturers still make 8-bit CPUs in significant quantities. If 8-
bit CPUs are still going strong after 28 years, what makes you think
32-bit CPUs will become museum pieces in 30?

It comes down to whether 32-bit CPUs are going to stick around, like 8-
bit CPUs did, or die a fast and horrible death, like 16-bit CPUs did.
I think they will die rather quickly because the circumstances that
keep 8-bit CPUs around are, IMO, fairly unique (lots of applications
that don't need high performance, so no reason to upgrade). But it's
dangerous to gamble.

DS