Removed "Don't do that" from docs and error messages.

It's slightly aggressive and doesn't explain itself.

docs/topics/db/managers.txt

@@ -228,9 +228,8 @@ model. In those situations, Django has to be able to see all the objects for
 the model it is fetching, so that *anything* which is referred to can be
 retrieved.
 
-If you override the ``get_queryset()`` method and filter out any rows, Django
-will return incorrect results. Don't do that. A manager that filters results
-in ``get_queryset()`` is not appropriate for use as a base manager.
+Therefore, you should not override ``get_queryset()`` to filter out any rows.
+If you do so, Django will return incomplete results.
 
 .. _calling-custom-queryset-methods-from-manager:
 

docs/topics/i18n/timezones.txt

@@ -495,10 +495,11 @@ Setup
    datetimes safely, their representation should include the UTC offset, or
    their values should be in UTC (or both!).
 
-   Finally, our calendar system contains interesting traps for computers::
+   Finally, our calendar system contains interesting edge cases. For example,
+   you can't always subtract one year directly from a given date::
 
        >>> import datetime
-       >>> def one_year_before(value):       # DON'T DO THAT!
+       >>> def one_year_before(value):  # Wrong example.
        ...     return value.replace(year=value.year - 1)
        >>> one_year_before(datetime.datetime(2012, 3, 1, 10, 0))
        datetime.datetime(2011, 3, 1, 10, 0)
@@ -507,9 +508,9 @@ Setup
        ...
        ValueError: day is out of range for month
 
-   (To implement this function, you must decide whether 2012-02-29 minus
-   one year is 2011-02-28 or 2011-03-01, which depends on your business
-   requirements.)
+   To implement such a function correctly, you must decide whether 2012-02-29
+   minus one year is 2011-02-28 or 2011-03-01, which depends on your business
+   requirements.
 
 #. **How do I interact with a database that stores datetimes in local time?**