#14253 closed New feature (fixed)
TIME_ZONE not respected by Today and Now widgets in admin
Reported by: | Adam Nelson | Owned by: | nobody |
---|---|---|---|
Component: | contrib.admin | Version: | 1.2 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Fixed on a branch | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | yes |
Description
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.
Change History (13)
comment:1 by , 14 years ago
comment:2 by , 14 years ago
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.
follow-up: 10 comment:3 by , 14 years ago
Triage Stage: | Unreviewed → Design decision needed |
---|
@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.
comment:4 by , 14 years ago
@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'.
comment:5 by , 14 years ago
@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.
comment:6 by , 14 years ago
@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:
- 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.
- Show the current time according to the server next to the now button and use the server's tz when 'now' is pushed
- Show the offset according to the server next to the now button and use the server's tz when 'now' is pushed
- Give an option to easily disable the 'now' button
- Give an option to use server time for the admin datetime widget
comment:7 by , 14 years ago
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] + "'));");
comment:8 by , 13 years ago
Severity: | → Normal |
---|---|
Type: | → New feature |
comment:9 by , 13 years ago
UI/UX: | set |
---|
comment:10 by , 13 years ago
Easy pickings: | unset |
---|---|
Triage Stage: | Design decision needed → Fixed on a branch |
comment:11 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:12 by , 11 years ago
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.
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.)