TIME_ZONE not respected by Today and Now widgets in admin

[Adam Nelson]

When clicking 'Today' or 'Now' for a datetime field in the admin, the timezone used is that of the client, not the server. The behavior should either be to silently convert the datetime from the client's to the server's and back again (other tickets address this issue more generally), or to use the timezone set by settings.TIME_ZONE. The first option should not be done in this ticket, a general solution to that issue can be done elsewhere in a far future milestone. The more specific problem is that an end user puts in 'now' and it's really wrong.

Note: Showing the end user what the server time is could make things more clear generally.

[Malcolm Tredinnick]

Hmm... this isn't clearly a bug. In fact, the current behaviour seems correct to me (although I appreciate why it's debatable). When I click on the "now" button, it puts my current time in (now for me). Ditto for today. And that's the time I'm telling the server about. We do have some inconsistency with timezone expectations in the backend, but I'm not sure admin should auto "correct" (which is auto-break in some expectations).

Still, the question remains what to do, since the server cannot know the client's idea of timezone offset. I'd really like to pass back the offset so that the server can decide (and admin might well change the time to its own timezone), but then what do you do when people are entering values in the server's timezone (correcting in their head)? We can't make everybody happy here, but it feels like making the time the user enters not make sense to them in their frame of reference is wrong.

(Realistically, of course, many people are admin'ing in the same timezone as their server, so this is a moot point, but I've definitely been aware of it before, particularly when on the road.)

[Adam Nelson]

I think the best solution is to show the user what time the server is in. This can be done nicely with "The server's timezone is 5 hours ahead of yours" or something. Then, the JavaScript should work in the server's timezone. It's really not the case that pushing "now" puts in what is now for the user since Django is using the server's timezone for all other actions.

[Russell Keith-Magee]

@adam - I disagree. If I press "now", and the time comes up as anything other than UTC+8 (my timezone), that will be confusing.

Ultimately, I suspect that this will end up being fixed as a result of addressing #2626. Leaving it as a separate DDN issue in case someone can come up with a better approach.

[Adam Nelson]

@russelm The issue is that if you push now and you're in UTC+8, the server will save the time in UTC+8. In the future, when the time is retrieved by another user, the server will use its timezone to render the time and it won't be the time at which you pushed 'now'.

[Russell Keith-Magee]

@adam - My point is that Django doesn't handle timezones well at the moment, and it's something that requires a systemic fix, not a cosmetic fix.

[Adam Nelson]

@russelm agreed

Just to clarify what this ticket is about: it narrows itself to saying that it's not 'now' if you're in UTC+8 and the time is saved as UTC+8 on a UTC-4 machine - that's 12 hours ago and is the nature of the problem in this ticket.

I think there are a few solutions:

1. Convert the timezone on submit. This is effectively the type of thing #2626 would do - it shouldn't happen here and I'm only including this option so it's understood that I'm not advocating this.
2. Show the current time according to the server next to the now button and use the server's tz when 'now' is pushed
3. Show the offset according to the server next to the now button and use the server's tz when 'now' is pushed
4. Give an option to easily disable the 'now' button
5. Give an option to use server time for the admin datetime widget

[dvanders]

In the meantime I'm using this nasty nasty hack for my app (to convert time to CET).

$ diff  DateTimeShortcuts.js.bak DateTimeShortcuts.js
48c48
<         now_link.setAttribute('href', "javascript:DateTimeShortcuts.handleClockQuicklink(" + num + ", new Date().strftime('" + get_format('TIME_INPUT_FORMATS')[0] + "'));");
---
>         now_link.setAttribute('href', "javascript:DateTimeShortcuts.handleClockQuicklink(" + num + ", new Date(new Date().getTime() + new Date().getTimezoneOffset() * 60000 + 3600000).strftime('" + get_format('TIME_INPUT_FORMATS')[0] + "'));");

[Aymeric Augustin]

Replying to russellm:

Ultimately, I suspect that this will end up being fixed as a result of addressing #2626.

Indeed, this is fixed in the timezone support branch -- see "Multiple timezone support for datetime representation" thread on django-developers.

[Aymeric Augustin]

I think we can consider this fixed at r17106, which addressed #2626.

[Aymeric Augustin]

In fact, time zone support isn't sufficient, because most sites won't have per-user time zones: it's a lot of work just to fix the "now" button in the admin. We still need the cosmetic fix in addition to the systemic fix. (That wasn't obvious at first; we did things in the right order.)

There's a new attempt to fix this in #20663.

[Aymeric Augustin <aymeric.augustin@…>]

In 7e6d852bac4de2d5ed2d5ddeabf71482d644ef51:

Fixed #20663 -- "Today" and "now" admin shortcuts.

Changed the shortcuts next to date and time intput widgets
to account for the current timezone.

Refs #7717, #14253 and #18768.