Hi Mark,
On 16.06.2011, at 5:40PM, Mark Wiebe wrote:
>> >>> np.datetime64('2011-06-16 02:03:04Z', 'D')
>> np.datetime64('0000-06-16','D')
>>
>> I've tried to track this down in datetime.c, but unsuccessfully so (i.e. I
>> could not connect it
>> to any of the dts->year assignments therein).
>>
> This is definitely perplexing. Probably the first thing to check is whether
> it's breaking during parsing or printing. This should always produce the same
> result:
>
> >>> np.datetime64('1970-03-23 20:00:00Z').astype('i8')
> 7070400
>
> But maybe the test_days_creation is already checking that thoroughly enough.
>
> Then, maybe printf-ing the year value at various stages of the printing, like
> in set_datetimestruct_days, after convert_datetime_to_datetimestruct, and in
> make_iso_8601_date. This would at least isolate where the year is getting
> lost.
>
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.
Cheers,
Derek
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
