From: Jef D. <jef...@ho...> - 2010-01-13 13:08:00
|
On 13/01/2010 13:06, Tor Lillqvist wrote: >> Or is there a reason why the patch is not (yet) applied? > > It would cause incompatibility between mingw compiled code before the > patch and mingw compiled code after the patch, perhaps? True, but I'm not asking to make the 64bit time_t the default, only to add support for the 64bit time_t (and related functions) so I can actually use them. > Really, the only sensible thing is to avoid using types like time_t in > the public API boundary of separately compiled chunks of code > (libraries). Just use an explicitly always 64-bit integer type instead > (making sure the type is "spelled" correctly for various > compiler/platforms. i.e. int64_t vs. __int64 vs. long long). That's exactly what I'm going to do. But it would be nice to also fix the year 2038 issue at the same time. At the moment, I can't do that with mingw. I also looked at using the win32 api functions directly. Writing replacements for time(), gmtime() and timegm() is easy using respectively the GetSystemTimeAsFileTime(), FileTimeToSystemTime() and SystemTimeToFileTime() functions. But localtime() and its inverse mktime() are a different story. There are three functions for localtime()/mktime() functionality: LocalFileTimeToFileTime(), TzSpecificLocalTimeToSystemTime() and SystemTimeToTzSpecificLocalTime(). But the first one is documented to be wrong with DST [1], and the second one is only available since Windows XP [2]. [1] http://msdn.microsoft.com/en-us/library/ms724277%28VS.85%29.aspx [2] http://msdn.microsoft.com/en-us/library/ms725485%28VS.85%29.aspx |