Bugfix use of datetime.datetime objects in call to get_last_an_time

[adybbroe]

Fix so a normal datetime.datetime object can be passed as well to the get last ascending node function.

Currently when running this code below:

import pyorbital.orbital
from datetime import datetime

tlefile = "/path/to/some/archived/tle/files/tle-202406250015.txt"

dtobj = datetime(2024, 6, 25, 11, 0, 18)
orb = pyorbital.orbital.Orbital('NOAA-20', tle_file=tlefile)
result = orb.get_last_an_time(dtobj)

you will get this kind of error:

File <some path>/pyorbital/pyorbital/orbital.py:172, in Orbital.get_last_an_time(self, utc_time)
    170 dt = np.timedelta64(10, 'm')
    171 t_old = utc_time
--> 172 t_new = t_old - dt
    173 pos0, vel0 = self.get_position(t_old, normalize=False)
    174 pos1, vel1 = self.get_position(t_new, normalize=False)

UFuncTypeError: ufunc 'subtract' cannot use operands with types dtype('O') and dtype('<m8[m]')

THis PR seeks to solve these kind of errors, allowing to pass a simple datetime.datetime object to the function, and not only numpy.datetime64 objects as seems to have been the case until now.

• Closes #xxxx
• Tests added
• Tests passed
• Passes flake8 pyorbital
• Fully documented

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.12%. Comparing base (8542447) to head (14db2a9).
Report is 18 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #159      +/-   ##
==========================================
+ Coverage   87.99%   88.12%   +0.12%     
==========================================
  Files          14       14              
  Lines        2241     2265      +24     
==========================================
+ Hits         1972     1996      +24     
  Misses        269      269              

Flag	Coverage Δ
unittests	88.12% <100.00%> (+0.12%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[coveralls]

coverage: 88.06% (+0.1%) from 87.933%
when pulling 14db2a9 on adybbroe:fix-bug-get_last_an_time
into 652b30d on pytroll:main.

[djhoese]

FYI in modern python times a datetime object is "supposed to" have a timezone defined on it. If you use this method of conversion here and a python datetime object has a timezone then you'll get a warning:

In [13]: now = dt.datetime.now(dt.timezone.utc)

In [14]: np.datetime64(now)
<ipython-input-14-019101e2dae5>:1: UserWarning: no explicit representation of timezones available for np.datetime64
  np.datetime64(now)
Out[14]: np.datetime64('2024-07-17T15:36:14.860486')

I think you could check if the datetime has a .tzinfo and if not then convert it to UTC and then drop the timezone (not sure how to do that yet) before passing it to np.datetime64 to avoid the warning. Or I guess you could drop any timezone information no matter what because you have defined this interface as expecting time in UTC. 🤔

[adybbroe]

Good point, thanks! I believe I am handling this now!?

[sfinkens]

Looking good! One minor comment regarding readability

[sfinkens]

I think readability could be improved by separating the datetime path from the datetime64 path, for example

if isinstance(utc_time, dt.datetime):
    if utc_time.tzinfo and utc_time.tzinfo != pytz.utc:
        raise AttributeError
    return utc_time.replace(tzinfo=None)
return utc_time

[djhoese]

I think this should be a ValueError. The AttributeError I think is more to say you tried to access an attribute that didn't exist. ValueError (in my opinion) is more like "you gave me a value that doesn't make sense".

[djhoese]

See my other previous comments for requested changes.

[sfinkens]

Agree with the value error, otherwise looks good to me!