Calendar selector for DateField defaults to wrong date when timezone is missmatching

[Eric Druid]

I have a server set to the time zone UTC and my browser set to CEST (UTC+2). The calendar helper will display the date before the selected one for date fields.

Steps to reproduce:

1. Set TIME_ZONE = 'UTC' in settings.py
2. Set timezone of local machine (where the browser is run from) to CEST
3. Create a DateField that is printed in a form on an object
4. Create an object
5. View the objects interface, open the calendar js helper and notice that the selected date is the day before what is printed in the input box.

This is repeatable without saving the object, just select a different date and reopen the calendar and the date before the one clicked is used.

This is tested using python 2.7.6, django 1.8 using Chromium 43.0.2357.81

[Aymeric Augustin]

Your date field must default to datetime.date.today(). This value is computed in the time zone you chose: TIME_ZONE = 'UTC'. You're seeing the expected behavior.

Django doesn't automatically set the time zone based on the browser's time zone for the reasons explained in the documentation: ​https://docs.djangoproject.com/en/1.8/topics/i18n/timezones/#selecting-the-current-time-zone

For date time fields, the admin displays a warning when the browser's time zone doesn't match the server's time zone. Perhaps we should do this for date fields as well.

[Eric Druid]

There is a warning for the mismatching timezone.

I'll attach an image displaying the problem.

In this case the Member object has the sql row:

 id | first_name | last_name | date_of_birth |        email         | gender 
----+------------+-----------+---------------+----------------------+--------
  1 | Eric       | Druid     | 1983-11-20    | eric.druid@gmail.com | m

The problem is the preselected 1983-11-19 rather than 1983-11-20.

It looks to me as if the javascript is converting the date (1983-11-20) in CEST as a timestamp (1983-11-20 00:00+2), then changing it to UTC (1983-11-19 22:00+0) and extracting the date (1983-11-19) and using that to mark the selected day.

[Eric Druid]

Missmatching date for text/calendar

[Tim Graham]

I can reproduce this.

[Sasha Gaevsky]

I have reproduced this in the master branch as well.

[Sasha Gaevsky]

​PR

[Tim Graham]

This is a regression in 1.8 caused by 25e06bca57c068d4b9e9b4221b16a667ccb0d38e.

[Tim Graham <timograham@…>]

In 44930cc:

Fixed #24980 -- Fixed day determination in admin calendar widget.

[Tim Graham <timograham@…>]

In 18bf062:

[1.9.x] Fixed #24980 -- Fixed day determination in admin calendar widget.

Backport of 44930cc4667268c20493d7e97387db2a97d61a26 from master

[Tim Graham <timograham@…>]

In 40601e5:

[1.8.x] Fixed #24980 -- Fixed day determination in admin calendar widget.

Backport of 44930cc4667268c20493d7e97387db2a97d61a26 from master

[Tim Graham]

Looks like this broke some selenium tests: admin_widgets.tests.DateTimePickerSeleniumFirefoxTests.test_calendar_nonday_class and test_calendar_selected_class

[Sasha Gaevsky]

Replying to timgraham:

Looks like this broke some selenium tests: admin_widgets.tests.DateTimePickerSeleniumFirefoxTests.test_calendar_nonday_class and test_calendar_selected_class

I'm looking into this.

[Sasha Gaevsky]

​PR

[Tim Graham <timograham@…>]

In ea754289:

Refs #24980 -- Fixed incorrect timezone handling in admin calendar widget.

[Tim Graham <timograham@…>]

In 835fff4:

[1.9.x] Refs #24980 -- Fixed incorrect timezone handling in admin calendar widget.

Backport of ea7542891a4e3638a695c58bd6f00658b7c85985 from master

[Tim Graham <timograham@…>]

In caeacd94:

[1.8.x] Refs #24980 -- Fixed incorrect timezone handling in admin calendar widget.

Backport of ea7542891a4e3638a695c58bd6f00658b7c85985 from master