|
Home > Archive > Unix Programming > January 2004 > Re: creating 64 bit date functions on platforms that have a 32bit
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: creating 64 bit date functions on platforms that have a 32bit
|
|
| Rich Teer 2004-01-23, 4:47 pm |
| On Sat, 1 Nov 2003, Stu wrote:
quote:
> I am well aware why functions like mktime() can't calculate dates past
> 2038 due to the 32 bit signed value limitation of time_t defintion.
[...]
quote:
> This is such a popular problem I am sure somebody must of thought of
> this
> or a similar solution. If so, would you mind sharing your source code.
> I am particularly interested in a "C" solution.
The "correct" answer to this problem is to use 64-bit processes.
Most platforms these days are 64-bit capable, so there's not really
any excuse for new code.
--
Rich Teer, SCNA, SCSA
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
| |
| Rich Teer 2004-01-23, 4:47 pm |
| On Sat, 1 Nov 2003, Stu wrote:
quote:
> I am well aware why functions like mktime() can't calculate dates past
> 2038 due to the 32 bit signed value limitation of time_t defintion.
[...]
quote:
> This is such a popular problem I am sure somebody must of thought of
> this
> or a similar solution. If so, would you mind sharing your source code.
> I am particularly interested in a "C" solution.
The "correct" answer to this problem is to use 64-bit processes.
Most platforms these days are 64-bit capable, so there's not really
any excuse for new code.
--
Rich Teer, SCNA, SCSA
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
| |
| Dragan Cvetkovic 2004-01-23, 4:49 pm |
| beefstu350@hotmail.com (Stu) writes:
quote:
> Maurizio Loreti <mlo@foobar.it> wrote in message news:<rmn0bdtxe6.fsf@mlinux.pd.infn.it>...
>
>
> You have to be kddding me with your post !! Okay it is obvious you
> found some obsecure sentence tucked away in some manually that
> probably has 10 inches of dust on it.
I would assume that C standard and POSIX standard (you can find the later
at www.opengroup.org) are pretty much relevant here and not at all obsecure
and/or gathering dust.
quote:
>
> But what do you mean by "If _you_ assume that time_t is an (unsigned)>
> 32-bits integer, _you_ won't be allowed to pass 2038; ".
>
quote:
> It is a 32 bit signed integer and I am looking for a solution for this
> problem other than changing my hardware/OS.
The point is that you should write C programs that use time_t and not
signed 32bit int since the implementation does not guarantee that time will
be measured using signed 32 bit int (as it happens to be today). Since
there are some 35 years till 2038, who knows what OS/hardware would you be
using by then and what would be the underlining implementation of time_t at
that time.
Bye, Dragan
--
Dragan Cvetkovic,
To be or not to be is true. G. Boole No it isn't. L. E. J. Brouwer
!!! Sender/From address is bogus. Use reply-to one !!!
| |
| Dragan Cvetkovic 2004-01-23, 4:49 pm |
| beefstu350@hotmail.com (Stu) writes:
quote:
> Maurizio Loreti <mlo@foobar.it> wrote in message news:<rmn0bdtxe6.fsf@mlinux.pd.infn.it>...
>
>
> You have to be kddding me with your post !! Okay it is obvious you
> found some obsecure sentence tucked away in some manually that
> probably has 10 inches of dust on it.
I would assume that C standard and POSIX standard (you can find the later
at www.opengroup.org) are pretty much relevant here and not at all obsecure
and/or gathering dust.
quote:
>
> But what do you mean by "If _you_ assume that time_t is an (unsigned)>
> 32-bits integer, _you_ won't be allowed to pass 2038; ".
>
quote:
> It is a 32 bit signed integer and I am looking for a solution for this
> problem other than changing my hardware/OS.
The point is that you should write C programs that use time_t and not
signed 32bit int since the implementation does not guarantee that time will
be measured using signed 32 bit int (as it happens to be today). Since
there are some 35 years till 2038, who knows what OS/hardware would you be
using by then and what would be the underlining implementation of time_t at
that time.
Bye, Dragan
--
Dragan Cvetkovic,
To be or not to be is true. G. Boole No it isn't. L. E. J. Brouwer
!!! Sender/From address is bogus. Use reply-to one !!!
| |
| Rich Teer 2004-01-23, 4:57 pm |
| On Sat, 1 Nov 2003, Stu wrote:
quote:
> I am well aware why functions like mktime() can't calculate dates past
> 2038 due to the 32 bit signed value limitation of time_t defintion.
[...]
quote:
> This is such a popular problem I am sure somebody must of thought of
> this
> or a similar solution. If so, would you mind sharing your source code.
> I am particularly interested in a "C" solution.
The "correct" answer to this problem is to use 64-bit processes.
Most platforms these days are 64-bit capable, so there's not really
any excuse for new code.
--
Rich Teer, SCNA, SCSA
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
| |
| Dragan Cvetkovic 2004-01-23, 4:58 pm |
| beefstu350@hotmail.com (Stu) writes:
quote:
> Maurizio Loreti <mlo@foobar.it> wrote in message news:<rmn0bdtxe6.fsf@mlinux.pd.infn.it>...
>
>
> You have to be kddding me with your post !! Okay it is obvious you
> found some obsecure sentence tucked away in some manually that
> probably has 10 inches of dust on it.
I would assume that C standard and POSIX standard (you can find the later
at www.opengroup.org) are pretty much relevant here and not at all obsecure
and/or gathering dust.
quote:
>
> But what do you mean by "If _you_ assume that time_t is an (unsigned)>
> 32-bits integer, _you_ won't be allowed to pass 2038; ".
>
quote:
> It is a 32 bit signed integer and I am looking for a solution for this
> problem other than changing my hardware/OS.
The point is that you should write C programs that use time_t and not
signed 32bit int since the implementation does not guarantee that time will
be measured using signed 32 bit int (as it happens to be today). Since
there are some 35 years till 2038, who knows what OS/hardware would you be
using by then and what would be the underlining implementation of time_t at
that time.
Bye, Dragan
--
Dragan Cvetkovic,
To be or not to be is true. G. Boole No it isn't. L. E. J. Brouwer
!!! Sender/From address is bogus. Use reply-to one !!!
| |
| Rich Teer 2004-01-23, 5:12 pm |
| On Sat, 1 Nov 2003, Stu wrote:
quote:
> I am well aware why functions like mktime() can't calculate dates past
> 2038 due to the 32 bit signed value limitation of time_t defintion.
[...]
quote:
> This is such a popular problem I am sure somebody must of thought of
> this
> or a similar solution. If so, would you mind sharing your source code.
> I am particularly interested in a "C" solution.
The "correct" answer to this problem is to use 64-bit processes.
Most platforms these days are 64-bit capable, so there's not really
any excuse for new code.
--
Rich Teer, SCNA, SCSA
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
| |
| Dragan Cvetkovic 2004-01-23, 5:13 pm |
| beefstu350@hotmail.com (Stu) writes:
quote:
> Maurizio Loreti <mlo@foobar.it> wrote in message news:<rmn0bdtxe6.fsf@mlinux.pd.infn.it>...
>
>
> You have to be kddding me with your post !! Okay it is obvious you
> found some obsecure sentence tucked away in some manually that
> probably has 10 inches of dust on it.
I would assume that C standard and POSIX standard (you can find the later
at www.opengroup.org) are pretty much relevant here and not at all obsecure
and/or gathering dust.
quote:
>
> But what do you mean by "If _you_ assume that time_t is an (unsigned)>
> 32-bits integer, _you_ won't be allowed to pass 2038; ".
>
quote:
> It is a 32 bit signed integer and I am looking for a solution for this
> problem other than changing my hardware/OS.
The point is that you should write C programs that use time_t and not
signed 32bit int since the implementation does not guarantee that time will
be measured using signed 32 bit int (as it happens to be today). Since
there are some 35 years till 2038, who knows what OS/hardware would you be
using by then and what would be the underlining implementation of time_t at
that time.
Bye, Dragan
--
Dragan Cvetkovic,
To be or not to be is true. G. Boole No it isn't. L. E. J. Brouwer
!!! Sender/From address is bogus. Use reply-to one !!!
|
|
|
|
|