time_t and __time64_t

[Ram Baruch]

Hi,
The example in the msdn for CTime::GetTime() is something like:

CTime t( 1999, 10, 20, 23, 50, 0 ); // 11:50 PM October 20, 1999
time_t osBinaryTime = t.GetTime(); // time_t defined in <time.h>
printf( "time_t = %ld\n", osBinaryTime );

but CTime::GetTime() returns __time64_t. There is a casting from the 64 bit
version to the 32 bit version.
Do we loose important information in this case?
If so, someone should fix this example!
Regards,
Ram.

[selvam]

Post by Ram Baruch
Hi,
CTime t( 1999, 10, 20, 23, 50, 0 ); // 11:50 PM October 20, 1999
time_t osBinaryTime = t.GetTime(); // time_t defined in <time.h>
printf( "time_t = %ld\n", osBinaryTime );
but CTime::GetTime() returns __time64_t. There is a casting from the 64 bit
version to the 32 bit version.
Do we loose important information in this case?

No. I think time functions declared in Pointers. It will automatically takes
memory from the Operation system version either 64bit or 32bit.

Post by Ram Baruch
If so, someone should fix this example!
Regards,
Ram.

Regards,
Selvam

[Mihai N.]

Post by Ram Baruch
but CTime::GetTime() returns __time64_t. There is a casting from the 64 bit
version to the 32 bit version.
Do we loose important information in this case?

Quote from the "time, _time64" doc:

<<
A call to time or _time64 can fail, however, if the date passed to the
function is:

Before midnight, January 1, 1970.
After 19:14:07, January 18, 2038, UTC (using time and time_t).
After 23:59:59, December 31, 3000, UTC (using _time64 and __time64_t).
It seems that 2038 will be the next Y2K.
Seems, far, but so was 2000 for the COBOL programmers long ago.
Hoping that my applications are so usefull to be arround in 2038,
I would start using the time64 family of functions :-)