Firstly, my opinion is that any change here apart from documentation is breaking. That includes the proposal in the PR to change the rounding mode from floor to round. I do not believe that should happen without a major version change (presumably if/when Dates becomes an upgradable stdlib), because it would change the behaviour of people’s programs.
Secondly, if DateTime remains a type which represents a whole number of fractions of a second (i.e., if it remains resolved to ms, µs, ns, etc.), then silent rounding should not happen when they are added to. Instead, an error should be thrown telling you to appropriately round any Dates time periods to the smallest-resolved time period that DateTime supports. This avoids bugs due to not knowing how the Dates library works in great detail, which you currently need in order to work with it.
More broadly, I would like to see in the future a stdlib Dates package where the DateTime had ns resolution. @JeffreySarnoff’s young but excellent NanoDates.jl I know takes the exact approach mentioned by @rafael.guerra and would provide that. But my understanding is that having a time type which interoperates with Dates is a challenge when it is not actually part of it. I don’t know whether NanoDates have vastly different performance to DateTimes for arithmetic.
Finally, although I think for many people an integral time type is important, it would also be nice if there could be the option of a DateTime-like type which had floating-point seconds. This would allow you to represent time continuously and accept any rounding errors.