`when_made_public` stamped with a naive datetime while USE_TZ is active - apps/jobs/views.py:510

`when_made_public` is stamped with `datetime.datetime.now()`, which is timezone-naive, while `USE_TZ = True`. Django emits a `RuntimeWarning` and interprets the value as being in the default timezone, so on any server not running in UTC the stored instant is wrong — and can be in the future.

## Offending code

https://github.com/Cloud-CV/EvalAI/blob/f8aff86a7e613c61fae3e4b0e5c0382fe3b52a25/apps/jobs/views.py#L510

```python
if is_public is True:
when_made_public = datetime.datetime.now()
request.data["when_made_public"] = when_made_public
```

`when_made_public` is a `DateTimeField`:

https://github.com/Cloud-CV/EvalAI/blob/f8aff86a7e613c61fae3e4b0e5c0382fe3b52a25/apps/jobs/models.py#L88

## Why it is wrong

`settings/common.py` sets `USE_TZ = True`, so Django expects aware datetimes:

https://github.com/Cloud-CV/EvalAI/blob/f8aff86a7e613c61fae3e4b0e5c0382fe3b52a25/settings/common.py#L156

`datetime.datetime.now()` returns a **naive** datetime (no `tzinfo`), unlike `django.utils.timezone.now()`:

```
>>> datetime.datetime.now()
datetime.datetime(2026, 9, 14, 23, 47, 13) # naive, local clock
>>> timezone.now()
datetime.datetime(2026, 9, 14, 18, 17, 13, tzinfo=datetime.timezone.utc)
```

Assigning the naive value to the field produces Django's warning:

```
RuntimeWarning: DateTimeField received a naive datetime (2026-09-14 23:47:13)
while time zone support is active.
```

Django then treats the naive value as already being in the default timezone rather than converting it, so the stored instant is offset by the server's UTC offset. On the machine I reproduced this on (UTC+5:30) the skew was **5h30m, into the future**:

```
value Django would store : 2026-09-14 23:47:23+00:00
actual current instant : 2026-09-14 18:17:23+00:00
skew : 5:29:59
```

This is also the only place in `apps/` that still does this. The codebase uses `timezone.now()` in **47** other places, including elsewhere in `apps/jobs/`, so this line is a deviation from the project's own convention rather than a deliberate choice.

## Relationship to #1277

#1277 reported this exact `RuntimeWarning` and proposed changing `when_made_public=datetime.datetime.now()` to `timezone.now()` — but explicitly as a **"Partial solution"**, scoped to `tests/unit/jobs/test_views.py`.

The tests were indeed migrated (`tests/unit/jobs/test_views.py` now uses `when_made_public=timezone.now()` in three places), but the **production** line in `apps/jobs/views.py` that actually writes to the database was never changed. The warning stopped appearing in test output, so the remaining half went unnoticed.

## What the user sees

- `when_made_public` is stored offset by the server's UTC offset, so "when did this submission become public" is wrong for any non-UTC deployment.
- The stored timestamp can be **in the future**, which breaks ordering and any reporting or filtering that assumes it is not.
- A `RuntimeWarning` is emitted on every visibility change, adding log noise.

## Steps to reproduce

1. Run the server with a non-UTC system timezone (for example `TZ=Asia/Kolkata`).
2. As a participant, `PATCH` a submission at
`/api/jobs/challenge//challenge_phase//submission/`
with `{"is_public": true}`.
3. Django logs `RuntimeWarning: DateTimeField received a naive datetime ... while time zone support is active.`
4. Inspect the row: `when_made_public` is ahead of the true instant by the server's UTC offset.

## Expected behaviour

- `when_made_public` is timezone-aware, matching `USE_TZ = True`.
- The stored value is the true instant regardless of the server's timezone, and is never in the future.
- No `RuntimeWarning` is emitted.

---

I have a one-line branch replacing the call with `timezone.now()` (already imported in that module) plus a regression test asserting the stored value is aware; I'll open a PR referencing this issue.

Read the visibility-change code at apps/jobs/views.py:510 and the DateTimeField in apps/jobs/models.py:88. Then review the related tests in tests/unit/jobs/test_views.py and run them; done means the stored timestamp is timezone-aware and no naive-datetime warning is emitted. The issue author says they already have a branch and plan to open a PR.

Written by the indexing model from the issue text.