Add TIME_ZONE as .env variable

[grantfitzsimmons]

Fixes #641

This approach does not set USE_TZ to True (docs), meaning Django will use naive datetimes in local time. See the following behavioral difference:

specify@9ce63bab5807:/opt/specify7$ ve/bin/python manage.py shell -c "from django.conf import settings; print(settings.USE_TZ)"
False

Setting	Stored in database	timezone.now()	Displayed in templates
USE_TZ = True	UTC (aware)	aware UTC datetime	converted to America/Chicago (aware)
USE_TZ = False	America/Chicago	naive local datetime	as-is America/Chicago (naive)

This means we are assuming all data and users will be in the same timezone. However, we still face challenges with daylight saving time (DST) and cross-zone consistency. Since we have set the timezone to America/Chicago for all users and it is uncommon to have users from different time zones, this is a first step toward improving timezone support.

In the future, we should support USE_TZ, but this should be done first to give users more choice for now. The reason I am not using this approach here is because of some roadblocks that require further development to resolve. @melton-jason describes the issue with his fix in this comment: #641 (comment), see his branch here

TODO: See #6818

Testing instructions

• Modify the TIME_ZONE variable in the .env file to one from this list: https://en.wikipedia.org/wiki/List_of_tz_zones_by_name
• Verify that the time zone selected is used for system timestamps
  • TimestampCreated and TimestampModified for various records, such as
    • WorkBench/Batch Edit data set timestamps
      
    • Notifications
      
    • Records entered via data entry (easiest to check via API)

    "timestampcreated": "2025-06-28T12:15:34",
    "timestampmodified": "2025-06-28T12:15:34",

• Verify the time zone is set in Django via command line

   ❯ docker exec -it specify7-specify7-1 /bin/bash
   	specify@32b007f73376:/opt/specify7$ ve/bin/python manage.py shell -c "from django.conf import settings; print(settings.TIME_ZONE)"
   	America/New_York

[Copilot]

Pull Request Overview

Adds support for configuring the Django TIME_ZONE via an environment variable, with a fallback default.

• Read TIME_ZONE from the environment in settings/__init__.py.
• Expose TIME_ZONE in the generated local_specify_settings.py via the Dockerfile.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
specifyweb/settings/init.py	Changed TIME_ZONE to be loaded from os.environ.get
Dockerfile	Added TIME_ZONE assignment in local_specify_settings.py

Comments suppressed due to low confidence (2)

specifyweb/settings/init.py:87

• Consider updating the comment above this line to note that TIME_ZONE is now configurable via the TIME_ZONE environment variable.

TIME_ZONE = os.environ.get('TIME_ZONE', 'America/Chicago')

specifyweb/settings/init.py:87

• Add a test to verify that settings.TIME_ZONE correctly reflects the TIME_ZONE environment variable to prevent regression.

TIME_ZONE = os.environ.get('TIME_ZONE', 'America/Chicago')

[grantfitzsimmons]

I spoke to @CarolineDenis while she was testing this:

There is currently some confusion between the time zones displayed in the application:

• The front-end displays timestamps in the user's browser time zone (e.g., CDT for me, EDT for her).
• The actual date and timestamp values (e.g. Thursday, December 2, 2021 at 1:24:40 PM) are based on the back-end time zone (controlled by the new TIME_ZONE environment variable in the PR).
• Relative time indicators like "last month" are also based on the browser's time zone, not the back-end.
• This results in a hybrid experience where absolute timestamps reflect the back-end, but the time zone label and relative times reflect the front-end/browser. This may cause user confusion, as the displayed time zone label (e.g., CDT/EDT) may not match the actual time zone used to generate the timestamp (which is an existing issue with our current approach)

I'll look at solving this within this PR, but might need to be a new issue.

[grantfitzsimmons]

In response to the earlier issues:

• The front-end displays timestamps in the user's browser time zone (e.g., CDT for me, EDT for her).
• The actual date and timestamp values (e.g. Thursday, December 2, 2021 at 1:24:40 PM) are based on the back-end time zone (controlled by the new TIME_ZONE environment variable in the PR).

I found that I could simply adjust the timeStyle for the DateTimeFormat globally to no longer show the time zone by switching it from long to medium:

Before: "Thursday, December 2, 2021 at 1:24:40 PM CDT" (shows browser timezone)
After: "Thursday, December 2, 2021 at 1:24:40 PM" (no timezone shown)

1. Removing the potentially incorrect timezone label from the tooltip
2. Still showing the full date and time information
3. Keeping the relative date functionality intact

---

As for the other points, we might want to expose the time zone set in the environment to the DateElement function so we can return the timezone identifier (e.g. CDT), but for now these two issues are going to be outside the scope of this PR:

• Relative time indicators like "last month" are also based on the browser's time zone, not the back-end.
• This results in a hybrid experience where absolute timestamps reflect the back-end, but the time zone label and relative times reflect the front-end/browser. This may cause user confusion, as the displayed time zone label (e.g., CDT/EDT) may not match the actual time zone used to generate the timestamp (which is an existing issue with our current approach)