[Numpy-discussion] code review/build & test for datetime business day API

Derek Homeier derek@astro.physik.uni-goettingen...
Thu Jun 16 20:18:51 CDT 2011

On 17.06.2011, at 2:02AM, Mark Wiebe wrote:

>> ok, that was a lengthy hunt, but it's in printing the string in make_iso_8601_date:
>>    tmplen = snprintf(substr, sublen, "%04" NPY_INT64_FMT, dts->year);
>>    fprintf(stderr, "printed %d[%d]: dts->year=%lld: %s\n", tmplen, sublen, dts->year, substr);
>> produces
>> >>> np.datetime64('1970-03-23 20:00:00Z', 'D')
>> printed 4[62]: dts->year=1970: 0000
>> numpy.datetime64('0000-03-23','D')
>> It seems snprintf is not using the correct format for INT64 (as I happened to do in fprintf before
>> realising I had to use "%lld" ;-) - could it be this is a general issue, which just does not show up
>> on little-endian machines because they happen to pass the right half of the int64 to printf?
>> BTW, how is this supposed to be handled (in 4 digits) if the year is indeed beyond the 32bit range
>> (i.e. >~ 0.3 Hubble times...)? Just wondering if one could simply cast it to int32 before print.
> I'd prefer to fix the NPY_INT64_FMT macro. There's no point in having it if it doesn't work... What is NumPy setting it to for that platform?
Of course (just felt somewhat lost among all the #defines). It clearly seems to be mis-constructed 
on PowerPC 32:
NPY_SIZEOF_LONG is 4, thus NPY_INT64_FMT is set to NPY_LONGLONG_FMT - "Ld", 
but this does not seem to handle int64 on big-endian Macs - explicitly printing "%Ld", dts->year 
also produces 0. 
Changing the snprintf format to "%04" "lld" produces the correct output, so if nothing else 
avails, I suggest to put something like 

#  elseif (defined(__ppc__)  || defined(__ppc64__))
     #define LONGLONG_FMT   "lld"      
     #define ULONGLONG_FMT  "llu"
#  else

into npy_common.h (or possibly simply "defined(__APPLE__)", since %lld seems to 
work on 32bit i386 Macs just as well).


More information about the NumPy-Discussion mailing list