USE_TZ=False causes failure in AdminEmailHandler during DST "fall back"

[Thomas Smith]

In the AdminEmailHandler, it renders the current time:
(the first one).

Server time: {{server_time|date:"r"}}

Over the weekend, in our server, which has USE_TZ=False, that resulted in an AmbiguousTimeError inside logger.exception(...):

try:
    do_some_stuff_that_might_fail()
except Exception:
    logger.exception()

So our attempt to quickly move on from a failure in do_some_stuff_that_might_fail() did not work and it crashed the application (since it was called from module-level code).

This occurred at 1:42 AM EDT, and of course stopped being a problem after 2:00 AM EST.

Desired behavior: render the admin email with an ambiguous time if needed, but don't throw an exception from inside the exception handler

Backtrace:

  File "our_app.py", line 298, in do_things_at_startup.py
    logger.exception(e)
  File "logging/__init__.py", line 1479, in exception
    Convenience method for logging an ERROR with exception information.
  File "logging/__init__.py", line 1481, in exception
    self.error(msg, *args, exc_info=exc_info, **kwargs)
  File "logging/__init__.py", line 1467, in error
    Log 'msg % args' with severity 'ERROR'.
  File "logging/__init__.py", line 1475, in error
    self._log(ERROR, msg, args, **kwargs)
  File "logging/__init__.py", line 1589, in _log
    self.handle(record)
  File "logging/__init__.py", line 1599, in handle
    self.callHandlers(record)
  File "logging/__init__.py", line 1661, in callHandlers
    hdlr.handle(record)
  File "logging/__init__.py", line 952, in handle
    self.emit(record)
  File "django/utils/log.py", line 120, in emit
    message = "%s\n\n%s" % (self.format(no_exc_record), reporter.get_traceback_text())
  File "django/views/debug.py", line 353, in get_traceback_text
    return t.render(c)
  File "django/template/base.py", line 170, in render
    return self._render(context)
  File "django/template/base.py", line 162, in _render
    return self.nodelist.render(context)
  File "django/template/base.py", line 938, in render
    bit = node.render_annotated(context)
  File "django/template/base.py", line 905, in render_annotated
    return self.render(context)
  File "django/template/base.py", line 988, in render
    output = self.filter_expression.resolve(context)
  File "django/template/base.py", line 698, in resolve
    new_obj = func(obj, *arg_vals)
  File "django/template/defaultfilters.py", line 729, in date
    return formats.date_format(value, arg)
  File "django/utils/formats.py", line 152, in date_format
    return dateformat.format(value, get_format(format or 'DATE_FORMAT', use_l10n=use_l10n))
  File "django/utils/dateformat.py", line 327, in format
    return df.format(format_string)
  File "django/utils/dateformat.py", line 42, in format
    pieces.append(str(getattr(self, piece)()))
  File "django/utils/dateformat.py", line 274, in r
    dt = make_aware(self.data, timezone=self.timezone)
  File "django/utils/timezone.py", line 242, in make_aware
    return timezone.localize(value, is_dst=is_dst)
  File "pytz/tzinfo.py", line 366, in localize
    raise AmbiguousTimeError(dt)

[Mariusz Felisiak]

Thanks for the report, however, Django 3.2 is the extended support so it doesn't receive bugfixes anymore (expect security patches) and Django 5.0+ no longer uses pytz. Finally, it's ​documented that pytz.AmbiguousTimeError may be raised during a DST transition in Django versions < 5.0.