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

Mark Wiebe mwwiebe at gmail.com
Thu Jun 16 11:40:59 EDT 2011


On Wed, Jun 15, 2011 at 5:16 PM, Derek Homeier <
derek at astro.physik.uni-goettingen.de> wrote:

> On 15.06.2011, at 1:34AM, Mark Wiebe wrote:
>
> > These functions are now fully implemented and documented. As always, code
> reviews are welcome here:
> >
> > https://github.com/numpy/numpy/pull/87
> >
> > and for those that don't want to dig into review C code, the commit for
> the documentation is here:
> >
> >
> https://github.com/m-paradox/numpy/commit/6b5a42a777b16812e774193b06da1b68b92bc689
> >
> > This is probably also another good place to do a merge to master, so if
> people could test it on Mac/Windows/other platforms that would be much
> appreciated.
> >
> Probaby not specifically related to the business day, but to this month's
> general datetime fix-up,
> under Python3 there are a number of test failures of the kinds quoted
> below.
> You can review a fix (plus a number of additional test extensions and
> proposed fix for other
> failures on master) at
> https://github.com/dhomeier/numpy/compare/master...dt_tests_2to3


Thanks for the testing and proposed fixes, I've added some comments to the
commits.


> Plus on Mac OS X 10.5 PPC there is a failure due to the fact that the new
> datetime64 appears
> to _always_ return 0 for the year part on this architecture:
>
> >>> date='1970-03-23 20:00:00Z'
> >>> np.datetime64(date)
> np.datetime64('0000-03-23T21:00:00+0100','s')
> >>> np.datetime64(date, 'Y')
> np.datetime64('0000','Y')
> >>> 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.

For the record, all tests pass with Python2.5-2.7 on OS X 10.5/10.6 i386 and
> x86_64.
>

Great!

Cheers,
Mark


> Cheers,
>                                                Derek
>
>
> FAIL: test_datetime_as_string (test_datetime.TestDateTime)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File
> "/Users/derek/lib/python3.2/site-packages/numpy/core/tests/test_datetime.py",
> line 970, in test_datetime_as_string
>    '1959')
>  File "/Users/derek/lib/python3.2/site-packages/numpy/testing/utils.py",
> line 313, in assert_equal
>    raise AssertionError(msg)
> AssertionError:
> Items are not equal:
>  ACTUAL: b'0000'
>  DESIRED: '1959'
>
> ======================================================================
> FAIL: test_days_creation (test_datetime.TestDateTime)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File
> "/Users/derek/lib/python3.2/site-packages/numpy/core/tests/test_datetime.py",
> line 287, in test_days_creation
>    (1900-1970)*365 - (1970-1900)/4)
>  File "/Users/derek/lib/python3.2/site-packages/numpy/testing/utils.py",
> line 256, in assert_equal
>    return assert_array_equal(actual, desired, err_msg, verbose)
>  File "/Users/derek/lib/python3.2/site-packages/numpy/testing/utils.py",
> line 706, in assert_array_equal
>    verbose=verbose, header='Arrays are not equal')
>  File "/Users/derek/lib/python3.2/site-packages/numpy/testing/utils.py",
> line 635, in assert_array_compare
>    raise AssertionError(msg)
> AssertionError:
> Arrays are not equal
>
> (mismatch 100.0%)
>  x: array(-25567, dtype='int64')
>  y: array(-25567.5)
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110616/f42f43e1/attachment.html>


More information about the NumPy-Discussion mailing list