Code

Opened 7 months ago

Closed 7 months ago

Last modified 7 months ago

#21074 closed Bug (fixed)

DateTimeField: Using localized_fields breaks timezone conversion

Reported by: mattaustin Owned by: aaugustin
Component: Forms Version: 1.6-beta-1
Severity: Release blocker Keywords: timezone localization forms
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

If I add a DateTimeField to the form's localized_fields Meta property (in order to get the date correctly formatted), then the rendered field value is no longer converted to the activated timezone. This also occurs when setting localized=True on the DateTimeField.

Using Django 1.6b2.

Attachments (0)

Change History (8)

comment:1 Changed 7 months ago by aaugustin

  • Needs documentation unset
  • Needs tests unset
  • Owner changed from nobody to aaugustin
  • Patch needs improvement unset
  • Status changed from new to assigned
  • Triage Stage changed from Unreviewed to Accepted
  • Type changed from Uncategorized to Bug

I wasn't aware of localized_fields. I'll look into it.

comment:2 Changed 7 months ago by aaugustin

  • Owner aaugustin deleted
  • Severity changed from Normal to Release blocker
  • Status changed from assigned to new

There's a good reason why I didn't know about localized_fields: they're a new feature in 1.6.

The corresponding ticket is #13546 and the commit is [756b81db].

Since it's a major bug in a new feature, I'm marking the ticket as a release blocker.

Since it isn't a bug in my code, I'm deassigning myself.

comment:3 Changed 7 months ago by aaugustin

  • Owner set to aaugustin
  • Severity changed from Release blocker to Normal
  • Status changed from new to assigned

Florian rightfully points out that, if the bug can be triggered by setting localize=True on a DateTimeField, it isn't new in 1.6. I'll have to deal with it.

comment:4 Changed 7 months ago by aaugustin

  • Severity changed from Normal to Release blocker

Phew, it's actually a regression in 1.6 introduced in [893d8de6] which fixed #18777.

Florian and I independently identified this commit through bisection.

Last edited 7 months ago by aaugustin (previous) (diff)

comment:5 Changed 7 months ago by Florian Apolloner <florian@…>

In 56743cf9e337826e4c615909570bb057142a6a7b:

Ensured that BoundField.as_widget always returns properly localized fields.

This is a follow-up to #18777 which improperly converted to strings in
prepare_value and as such caused regressions like #21074.

Refs #18777, #21074

comment:6 Changed 7 months ago by Florian Apolloner <florian@…>

In ece8d6521771635fb5e15d1093524b4f848608fa:

[1.6.x] Ensured that BoundField.as_widget always returns properly localized fields.

This is a follow-up to #18777 which improperly converted to strings in
prepare_value and as such caused regressions like #21074.

Refs #18777, #21074

Backport of 56743cf9e337826e4c615909570bb057142a6a7b from master.

comment:7 Changed 7 months ago by Aymeric Augustin <aymeric.augustin@…>

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

In e76dd4cd1a12f610698b8aa8854b0e0e1dfb21a2:

[1.6.x] Fixed #21074 -- Added tests for localized datetime fields.

Fields must render values in the current time zone.

This commit only contains tests because this ticket was just a symptom of
a regression from #18777 that was fixed separately.

Backport of 5444a9c from master.

comment:8 Changed 7 months ago by Aymeric Augustin <aymeric.augustin@…>

In 5444a9c68353d8108df1cf69c9557740d626a18d:

Fixed #21074 -- Added tests for localized datetime fields.

Fields must render values in the current time zone.

This commit only contains tests because this ticket was just a symptom of
a regression from #18777 that was fixed separately.

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.