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