64bit equivalent of VC++ time.h on linux?

[Aditi]

I am working around a problem called Y2038 bug.
http://groups.google.co.in/group/co...lnk=st&q=time.h+64+bit+linux#2816aaf1f50f863e

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
Thanks

 

[Victor Bazarov]

I am working around a problem called Y2038 bug.
http://groups.google.co.in/group/co...lnk=st&q=time.h+64+bit+linux#2816aaf1f50f863e

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>.

Since <time.h> is a standard C header, you may be trying too hard.
If you just let the compiler/library vendor worry about the proper
implementation, and do not rely on the fact that 'time_t' is a 32
bit signed number of seconds from January 1, 1970, you shouldn't
have to do anything.

The application already exists and I have to replace these 32bit time
structures with their 64bit equivalents.

Why do you think you have to? You just need a proper way of
calculating time differences instead of doing arithmetic directly
on the 'time_t' type.

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
Thanks

Suggestion: don't.

V

 

[Linonut]

* Victor Bazarov peremptorily fired off this memo:

Since <time.h> is a standard C header, you may be trying too hard.
If you just let the compiler/library vendor worry about the proper
implementation, and do not rely on the fact that 'time_t' is a 32
bit signed number of seconds from January 1, 1970, you shouldn't
have to do anything.


Why do you think you have to? You just need a proper way of
calculating time differences instead of doing arithmetic directly
on the 'time_t' type.

Also, on 64-bit systems (at least on my version of Linux), time_t is a
long int, and (for example) "date" and "cal" support years after 2038.

Where did you get that idea? Look at the header files on a 64-bit linux
system.

 

[Aditi]

* Victor Bazarov peremptorily fired off this memo:






Also, on 64-bit systems (at least on my version of Linux), time_t is a
long int, and (for example) "date" and "cal" support years after 2038.


Where did you get that idea? Look at the header files on a 64-bit linux
system.

I am using a 32bit system, instead of using a third party library I
wanted to know if there is a patch aruond the existing system
libraries like time.h?

 

[Aditi]

* Victor Bazarov peremptorily fired off this memo:






Also, on 64-bit systems (at least on my version of Linux), time_t is a
long int, and (for example) "date" and "cal" support years after 2038.


Where did you get that idea? Look at the header files on a 64-bit linux
system.

I am working on a 32-bit system and I was looking for patch around the
existing system libraries. Something like on this webpage?

I am not sure but what would this patch do?

http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-11/6048.html

 

[James Kanze]

Since <time.h> is a standard C header, you may be trying too
hard. If you just let the compiler/library vendor worry about
the proper implementation, and do not rely on the fact that
'time_t' is a 32 bit signed number of seconds from January 1,
1970, you shouldn't have to do anything.

First, there's no guarantee about time_t---all that's guaranteed
is that it is an arithmetic type (e.g. int, double, etc.). And
he's explained why the typical 32 bit Unix time_t won't
work---he has to deal with dates after the year 2038.

I'm tempted to say that time in Unix (and thus in C/C++) is
broken---a more accurate evaluation would be that it was
designed to solve one limited problem, but has since been used
in a lot of cases where it simply isn't applicable. For more
general use, you probably need something more general. (Boost
has support for time and dates, for example. I don't know
whether it's being considered for inclusion in the next standard
or not, however.)

Why do you think you have to? You just need a proper way of
calculating time differences instead of doing arithmetic
directly on the 'time_t' type.

Unix time on a 32 bit machine is limited to the years 1970-2038.
That's a very limiting restriction for a lot of things. (I
can't represent my birthdate in it, for example.)

I suspect that he really should drop <time.h> for this.

 

[Pete Becker]

(Boost
has support for time and dates, for example. I don't know
whether it's being considered for inclusion in the next standard
or not, however.)

A small part of it is currently in the draft standard, for use with the
threading library. The full Boost date-time library is slated for TR2,
which is not getting much work at the moment.

 

[Rainer Lehrig]

I would not worry about time.h
The width of the datafields might be changed when 2038 comes near.

We have our own handmade time class that is portable.
http://pvbrowser.de/pvbrowser/sf/manual/rllib/html/classrlTime.html

 

[Victor Bazarov]

[..]
I'm tempted to say that time in Unix (and thus in C/C++) is
broken

I am not certain why you would want to draw the conclusion that
if Unix time is broken, then so is C/C++ time. If you rely on
the time implementation specific to Unix, you have a very simple
case of platform specificity. The code as such is non-portable
and that's what the OP has, apparently.

---a more accurate evaluation would be that it was
designed to solve one limited problem, but has since been used
in a lot of cases where it simply isn't applicable. For more
general use, you probably need something more general. (Boost
has support for time and dates, for example. I don't know
whether it's being considered for inclusion in the next standard
or not, however.)



Unix time on a 32 bit machine is limited to the years 1970-2038.
That's a very limiting restriction for a lot of things. (I
can't represent my birthdate in it, for example.)

I suspect that he really should drop <time.h> for this.

The OP didn't say _for what_ he is using <time.h>. So, I would
not be as bold as to say he should drop it.

V

 

[James Kanze]

[..]
I'm tempted to say that time in Unix (and thus in C/C++) is
broken

I am not certain why you would want to draw the conclusion
that if Unix time is broken, then so is C/C++ time. If you
rely on the time implementation specific to Unix, you have a
very simple case of platform specificity. The code as such is
non-portable and that's what the OP has, apparently.

The underlying principles of time in C/C++ are based on the Unix
model.

[...]

The OP didn't say _for what_ he is using <time.h>. So, I would
not be as bold as to say he should drop it.

He did say that he needed dates beyond 2038. If he needs them
today, then the Unix/C/C++ model is not what he needs.

 

[James Kanze]

I would not worry about time.h
The width of the datafields might be changed when 2038 comes near.

The width of the data fields is already implementation
dependent, and varies over different machines I use. So you
can't use it today for anything external.

 

[Linonut]

* Aditi peremptorily fired off this memo:

I am not sure but what would this patch do?

http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-11/6048.html

Barking up the wrong tree. Check this out instead:

http://www.ofx.net/

There's an open source library for it, libofx.

 

[Matthias Buelow]

I am using a 32bit system, instead of using a third party library I
wanted to know if there is a patch aruond the existing system
libraries like time.h?

You can't just modify the runtime library since the kernel is also using
a 32-bit value for time_t (that is, the kernel _is_ using time_t, and
exports this to the userland, whereas on Windows, it probably is using
its own, different, time structures, and the Unixoid time_t is only used
in the library.)