Error in PyDev but not in the standard python interpreter

[Chris Angelico]

On Tue, Jun 24, 2014 at 11:28 PM, Fabien <fabien.maussion at gmail.com> wrote:
> So they are two instances of the same object but something in pyDev doesn't
> want to compare them. Any Hint?

Are they really instances of the same class? One of them comes from
/usr/local/lib/python3.3/dist-packages/netcdftime.py and the other
comes from /usr/lib/python3.3/datetime.py - so they might be virtually
identical (or they might not), but they're not the actual same class,
and when __lt__ does its isinstance check, it doesn't pass.

The real question is: Why is netCDF4 not using "import datetime" to
get its datetime? And I think that's best answered with this, lifted
from the netcdftime.utime docstring [1]:

"""
The datetime instances returned by C{num2date} are 'real' python datetime
objects if the date falls in the Gregorian calendar (i.e.
C{calendar='proleptic_gregorian', 'standard'} or C{'gregorian'} and
the date is after 1582-10-15). Otherwise, they are 'phony' datetime
objects which are actually instances of C{L{netcdftime.datetime}}.  This is
because the python datetime module cannot handle the weird dates in some
calendars (such as C{'360_day'} and C{'all_leap'}) which don't exist in any real
world calendar.
"""

(Similar info can be found in the docstring for netcdftime.datetime
itself, but without the examples.)

ISTM netcdftime.datetime should define __lt__() to permit comparisons
with either others of itself or datetime.datetime objects, but in the
absence of that, you're stuck with either ensuring that you're working
with Gregorian dates, or writing your own comparison function.

Good luck!

ChrisA

[1] https://code.google.com/p/netcdf4-python/source/browse/trunk/netcdftime.py?r=1117#522