Code

Opened 4 years ago

Closed 2 years ago

Last modified 9 months ago

#14253 closed New feature (fixed)

TIME_ZONE not respected by Today and Now widgets in admin

Reported by: adamnelson 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.

Attachments (0)

Change History (13)

comment:1 Changed 4 years ago by mtredinnick

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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.)

comment:2 Changed 4 years ago by adamnelson

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.

comment:3 follow-up: Changed 3 years ago by russellm

  • Triage Stage changed from Unreviewed to 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 Changed 3 years ago by adamnelson

@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 Changed 3 years ago by russellm

@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 Changed 3 years ago by adamnelson

@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

comment:7 Changed 3 years ago by 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] + "'));");

comment:8 Changed 3 years ago by julien

  • Severity set to Normal
  • Type set to New feature

comment:9 Changed 3 years ago by julien

  • UI/UX set

comment:10 in reply to: ↑ 3 Changed 2 years ago by aaugustin

  • Easy pickings unset
  • Triage Stage changed from Design decision needed to Fixed on a branch

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.

comment:11 Changed 2 years ago by aaugustin

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:12 Changed 10 months ago by aaugustin

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.

comment:13 Changed 9 months ago by 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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.