> IMHO we should only modify the rounding method used by
> datetime.datetime.fromtimestamp() and
> datetime.datetime.utcfromtimestamp(), other functions
> use the "right" rounding method.

Fine by me.  How about today? ;-)

The regression reported here must get repaired.  nearest/even is generally favored when there's a choice.

I personally _prefer_ add-a-half-and-chop in time contexts that need rounding, because it's more uniform.  That is, picturing a context that rounds to 1 digit for clarity, using a decimal system, with a uniformly spaced sequence of inputs on the first line, then a line with add-a-half-and-chop results, and then a line with nearest/even results:

0.0 0.5 1.0 1.5 2.0 2.5 3.0 3.5 input
0.0 1.0 1.0 2.0 2.0 3.0 3.0 4.0 add-a-half-and-chop
0.0 0.0 1.0 2.0 2.0 2.0 3.0 4.0 nearest/even

From the last (nearest/even) line, you'd never guess that the inputs were uniformly spaced; in the second line, you would.  nearest/even's "in a tie, sometimes go up, sometimes go down" is, IMO, unnatural in this context.

But it doesn't make a lick of real difference to timestamp functions.  We're not working in decimal, and people aren't going to be staring at hex patterns in output.  So I'd pick whichever is easier to implement.