> I don't think full nanosecond support is feasible to complete in the remaining weeks

This may be so, but I think the important part of that question is "what work needs to be done and what questions need to be answered?" If the answer is that we need to make 3 decisions and do the C implementation, that seems feasible to do in under a month. If the answer is that we've got 10 contentious UI issues and we probably want to go through the PEP process, I agree with your assessment of the timing. Regardless, we'll need to know what work needs to be done before we do it...

> but we can try to add nanoseconds to timedelta only.  The mixed datetime + timedelta ops will still truncate, but many time-related  operations will be enabled. I would even argue that when nanoseconds precision is required, it is more often intervals no longer than a few days and rarely a specific point in time.

To be honest, I don't find this very compelling and I think it will only confuse people. I think most people use `timedelta` to represent something you add or subtract to a `datetime`. Having the `nanoseconds` part of it truncate seems like it would be frustrating and counter-intuitive. 

From the use cases in this thread: 
 - ns-precision timestamps: https://bugs.python.org/issue15443#msg180125
 - ns-precision timestamps: https://bugs.python.org/issue15443#msg223039
 - Your suggestion that `datetime` should be able to support what `timespec` does: https://bugs.python.org/issue15443#msg223042
 - ns-precision timestamps: https://bugs.python.org/issue15443#msg270266

So I don't think there's high enough demand for nanosecond-timedelta on its own that we need to rush it out there before datetime gets it.