Objective a 64 bit version of some of the c time routines.

This lets you use 64 bit times with your app in a 32 bit build
and so makes it year 2038 compliant.

If anyone is still using your 32 bit build in 2038 as a legacy app they won't need
to re-build it.

It is implemented for some of the more commonly used c time routines. 
Others can be added easily.

For details and to check for latest version:

http://www.tunesmithy.co.uk/t64/index.htm

For support: Contact Robert Walker, support@tunesmithy.co.uk

To use this with your app:

#include "time64.h"

/* Note
 * When you include this header then all your time_t variables will become
 * __int64 variables.
 *
 * Be sure to check that routines that use them work with __int64 variables.
 * By way of example, if you use sprintf, fprintf, sscanf, fscanf etc 
 * then you won't be able to use the %d format field for these variables
 * in a 32 bit build - they will overflow and be used for the next format field
 * as well. Instead convert your variables to unsigned ints and use %lu
 *
 * e.g. 
 * sprintf(sz,"time_saved %lu secs",(UINT)time(NULL));
 *
 * {
 *  time_t time_saved=0;
 *  UINT utime_saved=0;
 *  sscanf( sz, "%*s%lu", &utime_saved);
 *   // read it in as an unsigned long as sscanf can't read to __int64 variables 
 *   // directly
 *   time_saved=utime_saved;
 * }
 *
 
 * Unsigned ints are fine for dates until beyond the end of this century
 *
 * If your compiler has some other type of native 64 bit type then
 * change the line typedef __int64 t64 
 */

Also as with the original <time.h> this implementation isn't thread safe
if you have several threads that simultaneously want to use the
structure returned by localtime(..)

However you may be able to make it so for apps by defining 

#define USE_THREAD_LOCAL_VARIABLES

in the header. 

You can't use this method with dlls if there is any chance they might be loaded 
using LoadLibrary.

Instead you would need to modify the source code to use thread local storage.

See
http://msdn.microsoft.com/library/en-us/dllproc/base/dynamic_link_library_data.asp

I'm also a little unsure about whether the pointer that you get back
from localtime can be kept for any length of time before accessing it if
you use thread local variables - as the MSVC help seems to suggest that the
address of a pointer to a thread local variable may change. If anyone knows more
about this please advise. Thanks.

It should be okay in C++ builds whatever, according to the help. anyway be sure
to read the section on thread local variables in your compiler help before
enabling this option.






