Consider switching to a repr with a zero-padded year? about cftime HOT 6 CLOSED

I think we could potentially fix this behavior on the xarray side, but ISO-8601 is pretty clear that all years should have four digits. So I still think this would be a win. Certainly 0001-01-01 is much clearer than 01-01-01.

from cftime.

Just checking in on this issue after a while -- so is the consensus that we should address this issue within netcdftime? If so, I can try to put together a PR.

from cftime.

I think the fundamental problem is that no one has stepped to maintain a separate netcdftime project. Seems like there is still some work to do before I can disconnect it from netcdf4-python.

from cftime.

I'm happy to help step up on the infrastructure side (well, in a couple weeks probably), but I'm a little uncomfortable with stepping up fully since I don't have much technical knowledge in the space netcdftime is operating. So I'm happy to cut releases and stuff, but I'm not in possession of answers when it comes to solutions to problems.

from cftime.

It occurs to me now that a possibly less disruptive solution than altering the current string representation of netcdftime datetimes would be to simply add an isoformat method, which we could use in xarray, analogous to datetime.datetime.isoformat or pd.Timestamp.isoformat. Would that be preferred over modifying __str__?

from cftime.

I don't think changing the repr/string format would be disruptive. I expect most users would agree that 0001-01-01 is clearer than 1-01-01.

That said, I have no objections to adding an isoformat() method, too.

from cftime.