Totally agree, but for this specific bug I think that the process can be improved by increased code reviews. The fact that a negative seconds inst var and a julianDayNumber inst var different from julianDayNumber message was chosen indicates that current implementation is a quick hack, a workaround for solving some problems, but clearly not a long term solution. IMO it creates as many problems as it solves.
That is a totally different discussion and most probably the tests are wrong, as with most of the date and time stuff from squeak. The dimensions of this mess are hard to grasp, but using a reference point expressed in local time is a very bad thing. So we changed that and all internal representations of DateAndTime are in UTC. All external representations of DateAndTime are in local time. That implies that whatever you inspect and see is in UTC, negative offsets make perfectly sense if your time-zone lags behind UTC. I wish I had time to fully clear up the mess, and add all basic accessors for utc.