Andrew Roach wrote:
At 11:47 AM 23/11/2007 -0800, you wrote:
The C library internal representation of time as a time_t variable does have
the well-known drawback you mentioned of a rather limited date range for
those systems where time_t is defined as a 32-bit integer, see discussion in
http://en.wikipedia.org/wiki/Year_2038_problem . Note, however, hardware is
rapidly moving to 64-bit right now. For example, my impression from a
recent computer buy is that 64-bit has become the norm rather than the
exception for new PC's. Thus, on PC's at least, I don't think the above
32-bit time_t issue is going to be relevant for too much longer.
Just to put things in context, even 32-bit versions of Windows now treats
time internally as an unsinged 64-bit int measured in 100 nanosecond
intervals from 1st January 1601.
Well, in that case, using strftime() and time_t ought to be okay for all
but the most
demanding applications. I just did not want such a new feature to be
hampered from
the beginning by a rather arbitrary limit. (Oh, I checked for MS Visual
C/C++ 6.0:
that uses a 32-bits type for time_t, version 7 uses a 64-bits type. And
my pretty old
MingW environment uses a 32-bits type.)
Regards,
Arjen
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
