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

[Aditi]

I am working around a problem called Y2038 bug.
http://groups.google.co.in/group/com...16aaf1f50f863e

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]

Aditi wrote:

I am working around a problem called Y2038 bug.
http://groups.google.co.in/group/com...16aaf1f50f863e

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.his 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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Linonut]

* Victor Bazarov peremptorily fired off this memo:

Aditi wrote:

>I am working around a problem called Y2038 bug.
http://groups.google.co.in/group/com...16aaf1f50f863e

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

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.

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

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

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

Suggestion: don't.

--
At Microsoft there are lots of brilliant ideas but the image is that they all
come from the top - I'm afraid that's not quite right.
-- Bill Gates

[Aditi]

On Feb 11, 9:29 pm, Linonut <[e-mail]:

* Victor Bazarov peremptorily fired off this memo:

Aditi wrote:

I am working around a problem called Y2038 bug.
http://groups.google.co.in/group/com...rowse_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>.

Since <time.his 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.

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.

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

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

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

Suggestion: don't.

--
At Microsoft there are lots of brilliant ideas but the image is that they all
come from the top - I'm afraid that's not quite right.
-- Bill Gates

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]

On Feb 11, 9:29 pm, Linonut <[e-mail]:

* Victor Bazarov peremptorily fired off this memo:

Aditi wrote:

I am working around a problem called Y2038 bug.
http://groups.google.co.in/group/com...rowse_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>.

Since <time.his 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.

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.

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

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

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

Suggestion: don't.

--
At Microsoft there are lots of brilliant ideas but the image is that they all
come from the top - I'm afraid that's not quite right.
-- Bill Gates

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-L...5-11/6048.html

[Pete Becker]

On 2008-02-12 05:16:27 -0500, James Kanze <ja*********@gmail.comsaid:

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

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[James Kanze]

On Feb 12, 3:01 pm, "Victor Bazarov" <[e-mail]:

James Kanze wrote:

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

[...]

I suspect that he really should drop <time.hfor 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.

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 (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Feb 12, 2:14 pm, Rainer Lehrig <[e-mail]:

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.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Linonut]

* Aditi peremptorily fired off this memo:

I am not sure but what would this patch do?

http://linux.derkeiler.com/Mailing-L...5-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.

--
God is not willing to do everything, and thus take away our free will and that
share of glory which belongs to us.
-- Niccolo Machiavelli

[Matthias Buelow]

Aditi wrote:

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