num2date uses 'proleptic_gregorian' scheme when basedate is post-Gregorian but date is pre-Gregorian

[stephenworsley]

Changes made in #180 have affected the behaviour of num2date. This has caused tests to fail for Iris SciTools/iris#3751. The following code was giving different results for cfunits version 1.1.3 and 1.2.0

import cftime
import cf_units

hrs_unit = cf_units.Unit(("hours since epoch", calendar=cf_units.CALENDAR_GREGORIAN)
hrs_unit.date2num(cftime.datetime(1,1,1))

It seems as though version 1.1.3 was using a 'gregorian'/'standard' calendar while version 1.2.0 was using a 'proleptic_gregorian' calendar.

As far as I can tell, this is due to the following line:

cftime/cftime/_cftime.pyx

Line 212 in 39df137

use_python_datetime = _can_use_python_datetime(basedate,calendar)

which decides to use default python datetimes for calculation when the basedate is beyond 1582,10,15. However, this does not account for cases where the date happens to be before this time. Should it be assumed that all dates ought to be after the basedate and therefore this change in behaviour is inconsequential to proper use of cftime? Or is this a geniune bug which ought to be fixed?

[jswhit]

probably that line should be changed to

use_python_datetime = _can_use_python_datetime(basedate,calendar) and calendar == 'proleptic_gregorian'

The main reason for wanting to use python datetimes if possible is to have the ability to deal with time zone offsets.

[jswhit]

Implemented a slightly different solution in PR #183. If this works for you I can put out a 1.2.1 release in the next couple of days.

[jswhit]

@stephenworsley - please let me know when you've had a chance to try this so I can merge and make a new release.

[stephenworsley]

@jswhit Sorry for the delay getting back to you, I've just been able to set up an environment with these changes and I can confirm that this does in fact fix our tests. Thanks for your time fixing this.

[jswhit]

Great, thanks! Look for a 1.2.1 release shortly.