In issue 2551417 Ross saw the following oddness in the logs:

127.0.0.1 - - [23/May/2026 02:07:10] "GET /demo/rest HTTP/1.1" 403 -
127.0.0.1 - - [22/May/2026 19:07:10] "GET /favicon.ico HTTP/1.1" 200 -
127.0.0.1 - - [23/May/2026 02:07:42] "GET /demo/index HTTP/1.1" 200 -
127.0.0.1 - - [23/May/2026 02:07:42] "GET /demo/rest HTTP/1.1" 403 -
127.0.0.1 - - [22/May/2026 19:08:57] "GET / HTTP/1.1" 302 -
127.0.0.1 - - [23/May/2026 02:08:57] "GET /demo/index HTTP/1.1" 200 -

note the change un timezone for / and /favicon to US/Pacific from the UTC
used by demo. This is because demo has the timezone set to utc in it's config.ini
while the server is in the Us/Pacific timezone. So / and /favicon are in server
timezone.

Do we fix this? If so how?

I think this can be improved. We can:

  1 override the timeformat setting for logger to include the timezone
  2 force timezone to GMT (since it doesn't have shifts like daylight savings)
  3 force the timezone to one set by the user

Within a tracker, the times are logged consistently in a single timezone.

Logging from different trackers can have different default timezones.

roundup-server when logging a url outside a tracker, logs using the server timezone.
When running wsgi under waitress I suspect a similar issue if you use logging middleware
to generate http style log records.

I am sort of leaning toward 1 and add timezones since defining the format should
take effect across the stack in a wsgi environment (provided logging occurs after
roundup initializes).

Thoughts?

Also this could be a doc bug and recommend that roundup-server be started by setting the TZ 
variable explicitly (I think this works):

  TZ=UTC roundup-server .....

Similar methods could work for gnuicorn, zope, mod-python etc where the server logs
independent of any tracker's timezone config.