Incorrect logic for determining if a unit is a date unit

[pelson]

I was looking to implement the separation of date from unit in pyudunits2 and took a look over the existing cf-units logic to determine if something is a time reference:

cf-units/cf_units/__init__.py

Line 891 in cdf7172

return self.calendar is not None

Then, I wondered how this calendar came to being...

cf-units/cf_units/__init__.py

Line 757 in cdf7172

if _OP_SINCE in unit.lower():

Which is surprising, because the existence of shift isn't a guarantee that it is a date. Take temperatures for example:

>>> degC = cf_units.Unit('kelvin since 273.15')
>>> degC.is_time_reference()
True

udunits2 does not delineate the type of shift that it does based on how shift is spelt. It is quite common to see degC defined as kelvin @ 273.15, which would return False for is_time_reference... but then so would:

>>> seconds_since_2000 = cf_units.Unit('seconds @ 2000-01-01T00:00 UTC')
>>> seconds_since_2000.is_time_reference()
False

I'm not clear is there is an actual way to fix this with udunits2. Date handling is messy, and highly context dependent as I am learning in pelson/pyudunits2#4

[stephenworsley]

Per CF Conventions:

UDUNITS permits a number of alternatives to the word since in the units of time coordinates. All the alternatives have exactly the same meaning in UDUNITS. For compatibility with other software, CF strongly recommends that since should be used.

It seems like there is some expectation that alternatives to since for time coordinates would not be fully supported, though I suppose the CF Conventions don't say anything aout non-time coordinates using since (as far as I can see).

The current logic ought to work for most cases which follow CF best practice (assuming that using since in non-time units is rare), but I agree it's messy and we'd certainly be interested in any improvements here.