jkanze@otelo.ibmmail.com wrote:
: In the Unix world, the general feeling seems to be that it is a non
: problem, on the grounds that long before the roll-over occurs, all
: systems will have 64 bit longs.  I find this a bit naive, since the
: time stamps that people have been writing on disk won't suddenly become
: 64 bits just because the OS changes (and the OS will have to offer
: support for these older time stamps).

I find it naive too, since I am pretty sure that there
still will be many programs compiled in the "compatibility
mode" and/or running on new hardware under simulators
for old one.

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I have already run up against this problem in software that I wrote that
predicts inspection dates for an aircraft.  We were using time_t for all
of our time-stamps until I found out that my code sometimes generated
inspection dates far past the 2038 limit.

jkanze@otelo.ibmmail.com wrote:

> In article <6indmu$kh6$1@nnrp1.dejanews.com>#1/1,
>   sclark@fds.com wrote:
> >
> > There is a common problem among C and C++ compilers involving the roll-over
> > of the time_t data type.  Many (most/all?) compilers typedef time_t as a
> long
> > and use 1-1-1970 as a reference date.  This leads to a date roll-over
> problem
> > in January 2038.
>
> This depends on the machine.  Quite a number of machines define long
> as 64 bits, which pushes the roll-over date back far enough that I'm
> not going to worry about it.  (The sun will burn-out before the roll
> over date.)
>
> > I have seen a lot written about this problem.  Most of it implies and some
> > clearly states that this is a problem with the C/C++ language and/or
> library.
>
> I've seen the problem mentioned from time to time (too rarely, IMHO).
> With only one exception, it was cited as a "Unix problem", not a C or
> a C++ problem.
>
> >  When I look at the language standard, it seems clear that both the type
> > definition for time_t and the reference date are entirely up to the
> > implementation of the compiler.
> >
> > Is it clear that this problem must be resolved in the compiler
> implementation
> > and not in the language standard?
>
> 100%.  In fact, in most cases, the "problem" is in the OS, and not the
> compiler implementation.
>
> In the Unix world, the general feeling seems to be that it is a non
> problem, on the grounds that long before the roll-over occurs, all
> systems will have 64 bit longs.  I find this a bit naive, since the
> time stamps that people have been writing on disk won't suddenly become
> 64 bits just because the OS changes (and the OS will have to offer
> support for these older time stamps).
>
> > Do the standard bodies need to provide
> > some guidance on this issue?
>
> The Posix standards committee probably should.  I don't see this as an
> issue for C/C++, however.
>

--
Greg Bonney - Greg.Bonney@hercii.mar.lmco.com
Disclaimer:  Opinions are strictly my own, not those of my employer, and
should not be construed as legal advice, etc.  E-mail can be forged.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6indmu$kh6$1@nnrp1.dejanews.com>#1/1,
  sclark@fds.com wrote:
>
> There is a common problem among C and C++ compilers involving the roll-over
> of the time_t data type.  Many (most/all?) compilers typedef time_t as a
long
> and use 1-1-1970 as a reference date.  This leads to a date roll-over
problem
> in January 2038.

This depends on the machine.  Quite a number of machines define long
as 64 bits, which pushes the roll-over date back far enough that I'm
not going to worry about it.  (The sun will burn-out before the roll
over date.)

> I have seen a lot written about this problem.  Most of it implies and some
> clearly states that this is a problem with the C/C++ language and/or
library.

I've seen the problem mentioned from time to time (too rarely, IMHO).
With only one exception, it was cited as a "Unix problem", not a C or
a C++ problem.

>  When I look at the language standard, it seems clear that both the type
> definition for time_t and the reference date are entirely up to the
> implementation of the compiler.
>
> Is it clear that this problem must be resolved in the compiler
implementation
> and not in the language standard?

100%.  In fact, in most cases, the "problem" is in the OS, and not the
compiler implementation.

In the Unix world, the general feeling seems to be that it is a non
problem, on the grounds that long before the roll-over occurs, all
systems will have 64 bit longs.  I find this a bit naive, since the
time stamps that people have been writing on disk won't suddenly become
64 bits just because the OS changes (and the OS will have to offer
support for these older time stamps).

> Do the standard bodies need to provide
> some guidance on this issue?

The Posix standards committee probably should.  I don't see this as an
issue for C/C++, however.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

There is a common problem among C and C++ compilers involving the roll-over
of the time_t data type.  Many (most/all?) compilers typedef time_t as a long
and use 1-1-1970 as a reference date.  This leads to a date roll-over problem
in January 2038.

I have seen a lot written about this problem.  Most of it implies and some
clearly states that this is a problem with the C/C++ language and/or library.
 When I look at the language standard, it seems clear that both the type
definition for time_t and the reference date are entirely up to the
implementation of the compiler.

Is it clear that this problem must be resolved in the compiler implementation
and not in the language standard?  Do the standard bodies need to provide
some guidance on this issue?

Here are some web sites for reference:

Year 2000 FAQ
ftp://www.year2000.com/pub/year2000/y2kfaq.txt

MSDN
http://www.microsoft.com/msdn/news/scope/042298.htm

MS TechNet
http://www.microsoft.com/ithome/topics/year2k/product/ctime.htm

Steve Clark

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]