Re: [Django] #30578: SelectDateWidget doesn't use DATE formats properly when settings.USE_L10N=False. (was: L10N settings conflict with SelectDateWidget)

[Django]

#30578: SelectDateWidget doesn't use DATE formats properly when
settings.USE_L10N=False.
-+-
 Reporter:  fensta   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  Locale,  | Triage Stage:  Accepted
  SelectDateWidget   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * version:  2.2 => master
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report. I confirmed that there is an issue with this
 configuration, but I don't think that your patch is correct.
 `get_format()` should be used with and without `USE_L10N`, e.g.
 {{{#!python
 if y is not None and m is not None and d is not None:
 input_format = get_format('DATE_INPUT_FORMATS')[0]
 try:
 date_value = datetime.date(int(y), int(m), int(d))
 date_value = datetime_safe.new_date(date_value)
 return date_value.strftime(input_format)
 except ValueError:
 # Return pseudo-ISO dates with zeros for any unselected values,
 # e.g. '2017-0-23'.
 return '%s-%s-%s' % (y or 0, m or 0, d or 0)
 return data.get(name)
 }}}

 Reproduced at 036362e0cfe74e4ab8a65b99eb2aa9c35371fc04.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.ecb7887be8589667d94dd384ea9aa50d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30557: order_by() a parent model crash when Meta.ordering contains expressions.

[Django]

#30557: order_by() a parent model crash when Meta.ordering contains expressions.
-+-
 Reporter:  Jonny Fuller |Owner:  Eran
 |  Keydar
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ordering | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Eran Keydar):

 * has_patch:  0 => 1


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.5e6dfbffbd045fd0e760c1a8078d6bef%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30557: order_by() a parent model crash when Meta.ordering contains expressions.

[Django]

#30557: order_by() a parent model crash when Meta.ordering contains expressions.
-+-
 Reporter:  Jonny Fuller |Owner:  Eran
 |  Keydar
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ordering | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Eran Keydar):

 https://github.com/django/django/pull/11489

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.0c28edb2494770e3daa0627c4fa330b6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30576: Code not working on Django Tutorial part 6. (was: Code not working on Django Tutorial part 6)

[Django]

#30576: Code not working on Django Tutorial part 6.
-+-
 Reporter:  Javier Carrasco  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 |  worksforme
 Keywords:  django, tutorial,| Triage Stage:
  background, image  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by felixxm):

 * status:  new => closed
 * has_patch:  1 => 0
 * version:  2.2 => master
 * resolution:   => worksforme


Comment:

 Tutorial 06 works for me. Probably you've made some mistakes with
 directories, `background.gif` should be inside
 `polls/static/polls/images`.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.76f71c3a590873df3306ef7dd3fd9677%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30578: L10N settings conflict with SelectDateWidget

[Django]

#30578: L10N  settings conflict with SelectDateWidget
-+-
   Reporter:  fensta |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Forms  |Version:  2.2
   Severity:  Normal |   Keywords:  Locale,
   Triage Stage: |  SelectDateWidget
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I think I found a bug in Django related to L10N.  I'm using a
 SelectDateWidget in my ModelForm and want it displayed in the order  at the frontend. Therefore, I set
 {{{
 #!div style="font-size: 80%"
   {{{#!python
   USE_L10N=False
   }}}
 }}}
 in settings.py so that my custom order specified in DATE_FORMAT takes
 precedence. In my case, I defined it in settings.py as

 {{{
 #!div style="font-size: 80%"
   {{{#!python
   DATE_FORMAT="d M Y"
   }}}
 }}}

 Moreover, I also set

 {{{
 #!div style="font-size: 80%"
   {{{#!python
 DATE_INPUT_FORMATS = [
 "%d.%m.%Y",
 ]
  }}}
 }}}

 However, validating any dates on the server yielded invalid dates and my
 custom clean method for my field wasn't called. When looking at the source
 code for SelectDateWidget, I found value_from_datadict():

 {{{
 #!div style="font-size: 80%"
   {{{#!python
 def value_from_datadict(self, data, files, name):
 y = data.get(self.year_field % name)
 m = data.get(self.month_field % name)
 d = data.get(self.day_field % name)
 if y == m == d == '':
 return None
 if y is not None and m is not None and d is not None:
if settings.USE_L10N:  ## <-- This is the line
 input_format = get_format('DATE_INPUT_FORMATS')[0]
 try:
 date_value = datetime.date(int(y), int(m), int(d))
 except ValueError:
 pass
 else:
 date_value = datetime_safe.new_date(date_value)
 return date_value.strftime(input_format)
 # Return pseudo-ISO dates with zeros for any unselected
 values,
 # e.g. '2017-0-23'.
 return '%s-%s-%s' % (y or 0, m or 0, d or 0)
 return data.get(name)
   }}}
 }}}

 Shouldn't the highlighted if condition be instead?

 {{{
 #!div style="font-size: 80%"
   {{{#!python
 if not settings.USE_L10N:
   }}}
 }}}

 As far as I understand the code, without the added negation above the
 default date format ("year-month-day") will be used all the time. But
 since I explicitly disabled L10N in the settings, I was expecting that
 DATE_INPUT_FORMATS will be used instead of the default format. Of course,
 I could be wrong as I just started with Django, so apologies in advance if
 I misunderstood something and the code is correct as it is right now.

 Thanks in advance,
 Stefan

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/049.4b03d8474ea4a4413a6ed33ec7c0075d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30577: feature request: custom rendering for readonly fields in admin

[Django]

#30577: feature request: custom rendering for readonly fields in admin
-+
   Reporter:  David  |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  contrib.admin  |Version:  2.2
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 The new view permission is extremely useful, and encourages more use of
 the Django Admin tool. It has highlighted a limitation in the rendering of
 `readonly_fields` that can be easily addressed. At the moment,
 `readonly_fields` (or all fields when the user has only `can_view`) can
 only have custom rendering or formatting if they are custom properties or
 new fields (created in the ModelAdmin), existing fields can't be changed.
 In my use-case I have a number of rich text enhanced `TextField`s, which
 when rendered as read-only show up as HTML and can't be marked safe. In
 this case creating a custom field in the `ModelAdmin` where the Field can
 be output with `mark_safe()` doesn't work as the original field needs to
 exist for users with change permissions, the only other way is to include
 the field twice which creates UX issues.

 If, in ModelAdmin, you could override the formatting/output of a read-only
 field it would address this issue. Alternatively, as mentioned in the
 comments of #14802, the idea of Fields having a method that is called by
 admin to handle the read-only HTML rendering would also do the trick as is
 related.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/049.37e291a797513ee680ad2f9c741c9341%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30576: Code not working on Django Tutorial part 6

[Django]

#30576: Code not working on Django Tutorial part 6
-+-
   Reporter:  javiercmh  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component: |Version:  2.2
  Documentation  |   Keywords:  django, tutorial,
   Severity:  Normal |  background, image
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 In the section "Adding a background-image" (Part 6 of Django tutorial)
 teaches how to add a background image by editing style.css as follows:
 {{{#!css
   body {
 background: white url("images/background.gif") no-repeat;
   }
 }}}
 However, this won't work because it doesn't reference the actual location
 of the image file. The following change fixes the issue (add
 **''/static/''**):
 {{{#!css
   body {
 background: white url("/static/images/background.gif") no-repeat;
   }
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.edbf8b600595f946c94d5fb184ca9f2e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21080: collectstatic post-processing fails for references inside comments

[Django]

#21080: collectstatic post-processing fails for references inside comments
-+-
 Reporter:  shreyas@…|Owner:  Nathan
 |  Gaberel
 Type:  Bug  |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * needs_better_patch:  0 => 1


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/075.8d6c49dd77c4870585886683c104536d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30571: Incorrect value of kwargs in pre_init signal documentation.

[Django]

#30571: Incorrect value of kwargs in pre_init signal documentation.
-+-
 Reporter:  singhpratyush|Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  2.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  signals  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by felixxm):

 * status:  assigned => closed
 * resolution:   => invalid


Comment:

 Ahh, sorry but I just realized that everything works properly. If you will
 change your method signature, to the
 {{{
 @receiver(signals.pre_init, sender=user_models.Follower)
 def prevent_user_following_self(sender, args, kwargs, **other):
 print(kwargs)
 print(args)
 }}}
 then you will get `args` and `kwargs` as described in
 [https://docs.djangoproject.com/en/2.2/ref/signals/#pre-init
 documentation].

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.07ff1aaa8597220667037f9bce1d9b32%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30565: HttpResponseBase.close not called when using FileResponse / WSGI "file wrapper" object

[Django]

#30565: HttpResponseBase.close not called when using FileResponse / WSGI "file
wrapper" object
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 |  Jerdonek
 Type:  Bug  |   Status:  assigned
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  HttpResponse,| Triage Stage:  Accepted
  streaming, StreamingHttpResponse   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * owner:  nobody => Chris Jerdonek
 * status:  new => assigned
 * has_patch:  0 => 1


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.ec2ce7f22b73d7b4150526daca2e3482%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30575: Union of TruncBase annotations with different tzinfo apply `convert_value` of last tzinfo. (was: Union of TruncBase annotations with different tzinfo apply `convert_value` of last

[Django]

#30575: Union of TruncBase annotations with different tzinfo apply 
`convert_value`
of last tzinfo.
-+-
 Reporter:  Jurgis Pralgauskis   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:  timezone,| Triage Stage:
  TruncBase, Union, PostgreSQL   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * status:  new => closed
 * version:  1.11 => master
 * resolution:   => worksforme


Comment:

 Thanks for the report, however ticket description is not correct. Django
 uses `tzinfo` properly in your use case:
 {{{
 SELECT
 ...
 DATE_TRUNC('second', "ticket_30575_message"."timestamp" AT TIME ZONE
 'UTC') AS "trunc_local_time",
 UTC AS "tzname"
 FROM "ticket_30575_message" WHERE "ticket_30575_message"."timezone" = UTC
 UNION
 SELECT
 ...
 DATE_TRUNC('second', "ticket_30575_message"."timestamp" AT TIME ZONE
 'America/Los_Angeles') AS "trunc_local_time",
 America/Los_Angeles AS "tzname"
 FROM "ticket_30575_message" WHERE "ticket_30575_message"."timezone" = UTC)
 }}}
 i.e. `UTC` in a `qs1` and `America/Los_Angeles` in qs2. You can add
 `tzname` to you queryset (e.g. `tzname=Value(tzname,
 output_field=CharField())`) to check that everything works properly:
 {{{
 >>> for x in result:
 >>> print(x.timestamp, x.trunc_local_time, x.tzname)
 2019-06-18 10:07:04.111245+00:00 2019-06-18 03:07:04+00:00
 America/Los_Angeles
 2019-06-18 10:07:04.111245+00:00 2019-06-18 10:07:04+00:00 UTC
 }}}

 Closing per TicketClosingReasons/UseSupportChannels.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.e79539260a85c2a3776af06fb865b9a1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26739: Backward operation for RemoveField does not allow a default value in case the field is not null.

[Django]

#26739: Backward operation for RemoveField does not allow a default value in 
case
the field is not null.
+-
 Reporter:  Gagaro  |Owner:  Markus Holtermann
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+-
Changes (by wkoot):

 * cc: wkoot (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.09a901aa8d4f60c16eb901f79b37c528%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30575: Union of TruncBase annotations with different tzinfo apply `convert_value` of last tzinfo (PostgreSQL)

[Django]

#30575: Union of TruncBase annotations with different tzinfo   apply
`convert_value` of last tzinfo (PostgreSQL)
-+-
 Reporter:  Jurgis Pralgauskis   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  timezone,| Triage Stage:
  TruncBase, Union, PostgreSQL   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Jurgis Pralgauskis:

Old description:

> {{{#!python
> class Message(models.Model):
> timestamp = models.DateTimeField(auto_now=True) # PostgreSQL,
> USE_TZ=True
> msg = models.CharField(max_length=254)
> timezone = models.CharField(max_length=64, default="UTC",
> help_text="pytz name")
> }}}
>
> {{{#!python
> def test_demo_bug(self):
> from ..models import Message
> import pytz
> from django.db.models.functions import Trunc, TruncSecond
> import mock
> from django.utils import timezone
>
> with patch.object(timezone, 'now',
> return_value=pytz.utc.localize(datetime(2017, 1, 1, 0, 0))):
>
> # we have info
> Message.objects.create( msg = "bar", timezone = 'UTC')
> Message.objects.create( msg = "foo", timezone =
> 'America/Los_Angeles')
>

> # we want to get it with "localized" timestamps:
> qs = Message.objects.all()
>
> partitions = []  # partition by timezones
> for tzname in ['UTC', 'America/Los_Angeles']:
> tz = pytz.timezone(tzname)
> _qs = qs.filter(timezone='UTC')
> _qs =
> _qs.annotate(trunc_local_time=TruncSecond('timestamp', tzinfo=tz))
> partitions.append(_qs)
>
> qs1, qs2 = partitions
>
> result = list(qs1.union(qs2))
>
> for x in result:
> tz = pytz.timezone(x.timezone)
> print(x.msg)
> x.timestamp_trunc = x.timestamp.replace(microsecond=0)
> x.expected = x.timestamp_trunc.astimezone(tz)  # this is
> the working way  (but I wanted to get localization in DB layer)
> assert x.trunc_local_time == x.expected,  "Error (msg:
> '{x.msg}'): {x.trunc_local_time} != {x.expected}".format(x=x)
>
> }}}
>
> {{{
> Failure
> Traceback (most recent call last):
>   File "/home/jurgis/dev/new/tableair/sync_tableair-
> cloud/ta/api/booking/tests/test_endpoints.py", line 1107, in
> test_demo_bug
> assert x.trunc_local_time == x.expected,  "Error (msg: '{x.msg}'):
> {x.trunc_local_time} != {x.expected}".format(x=x)
> AssertionError: Error (msg: 'bla'): 2016-12-31 16:00:00+00:00 !=
> 2017-01-01 00:00:00+00:00}}}

New description:

 {{{#!python
 class Message(models.Model):
 timestamp = models.DateTimeField(auto_now=True) # PostgreSQL,
 USE_TZ=True
 msg = models.CharField(max_length=254)
 timezone = models.CharField(max_length=64, default="UTC",
 help_text="pytz name")
 }}}

 {{{#!python
 def test_demo_bug(self):
 from ..models import Message
 import pytz
 from django.db.models.functions import Trunc, TruncSecond
 import mock
 from django.utils import timezone

 with patch.object(timezone, 'now',
 return_value=pytz.utc.localize(datetime(2017, 1, 1, 0, 0))):

 # we have info
 Message.objects.create( msg = "bar", timezone = 'UTC')
 Message.objects.create( msg = "foo", timezone =
 'America/Los_Angeles')


 # we want to get it with "localized" timestamps:
 qs = Message.objects.all()

 partitions = []  # partition by timezones
 for tzname in ['UTC', 'America/Los_Angeles']:
 tz = pytz.timezone(tzname)
 _qs = qs.filter(timezone='UTC')
 _qs =
 _qs.annotate(trunc_local_time=TruncSecond('timestamp', tzinfo=tz)) # could
 be Trunc_anything_
 partitions.append(_qs)

 qs1, qs2 = partitions

 result = list(qs1.union(qs2))

 for x in result:
 tz = pytz.timezone(x.timezone)
 print(x.msg)
 x.timestamp_trunc = x.timestamp.replace(microsecond=0)
 x.expected = x.timestamp_trunc.astimezone(tz)  # this is
 the working way  (but I wanted to get localization in DB layer)
 assert x.trunc_local_time == x.expected,  "Error (msg:
 '{x.msg}'): {x.trunc_local_time} != {x.expected}".format(x=x)

Re: [Django] #30575: Union of TruncBase annotations with different tzinfo apply `convert_value` of last tzinfo (PostgreSQL)

[Django]

#30575: Union of TruncBase annotations with different tzinfo   apply
`convert_value` of last tzinfo (PostgreSQL)
-+-
 Reporter:  Jurgis Pralgauskis   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  timezone,| Triage Stage:
  TruncBase, Union, PostgreSQL   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jurgis Pralgauskis):

 * cc: Jurgis Pralgauskis (added)
 * type:  Uncategorized => Bug


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.506cf92a998bf37fa7fe2233ac7a0861%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30575: Union of TruncBase annotations with different tzinfo apply `convert_value` of last tzinfo (PostgreSQL)

[Django]

#30575: Union of TruncBase annotations with different tzinfo   apply
`convert_value` of last tzinfo (PostgreSQL)
-+-
 Reporter:  Jurgis Pralgauskis   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  timezone,| Triage Stage:
  TruncBase, Union, PostgreSQL   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jurgis Pralgauskis):

 workarounds are:

 - to take initial query and later adapt
 {{{
 tz = pytz.timezone(x.timezone)
 x.timestamp.astimezone(tz)
 }}}

 - or just make separate queries per timezone and chain (kind of union)
 them in python

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.eba0a7874a5cf67cd8764fb4e71309c4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30565: HttpResponseBase.close not called when using FileResponse / WSGI "file wrapper" object

[Django]

#30565: HttpResponseBase.close not called when using FileResponse / WSGI "file
wrapper" object
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  HttpResponse,| Triage Stage:  Accepted
  streaming, StreamingHttpResponse   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Chris Jerdonek):

 FYI, I posted a PR for this here:
 https://github.com/django/django/pull/11484

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.b6a4057d0c99db5f7b88744b3b3d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30575: Union of TruncBase annotations with different tzinfo apply `convert_value` of last tzinfo (PostgreSQL)

[Django]

#30575: Union of TruncBase annotations with different tzinfo   apply
`convert_value` of last tzinfo (PostgreSQL)
-+-
 Reporter:  Jurgis Pralgauskis   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  timezone,| Triage Stage:
  TruncBase, Union, PostgreSQL   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jurgis Pralgauskis):

 related idea, using CASE/WHEN, gives localized (but naive) datetime
 (because it just don't apply  `BaseTrunc.convert_value`
 https://mjec.blog/2016/06/27/djangos-queryset-union-isnt-quite-what-it-
 seems/

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.0b86fc607dc8798935617232163d52c8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30575: Union of TruncBase annotations with different tzinfo apply `convert_value` of last tzinfo (PostgreSQL)

[Django]

#30575: Union of TruncBase annotations with different tzinfo   apply
`convert_value` of last tzinfo (PostgreSQL)
-+-
   Reporter:  Jurgis |  Owner:  nobody
  Pralgauskis|
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  1.11
  layer (models, ORM)|   Keywords:  timezone,
   Severity:  Normal |  TruncBase, Union, PostgreSQL
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 {{{#!python
 class Message(models.Model):
 timestamp = models.DateTimeField(auto_now=True) # PostgreSQL,
 USE_TZ=True
 msg = models.CharField(max_length=254)
 timezone = models.CharField(max_length=64, default="UTC",
 help_text="pytz name")
 }}}

 {{{#!python
 def test_demo_bug(self):
 from ..models import Message
 import pytz
 from django.db.models.functions import Trunc, TruncSecond
 import mock
 from django.utils import timezone

 with patch.object(timezone, 'now',
 return_value=pytz.utc.localize(datetime(2017, 1, 1, 0, 0))):

 # we have info
 Message.objects.create( msg = "bar", timezone = 'UTC')
 Message.objects.create( msg = "foo", timezone =
 'America/Los_Angeles')


 # we want to get it with "localized" timestamps:
 qs = Message.objects.all()

 partitions = []  # partition by timezones
 for tzname in ['UTC', 'America/Los_Angeles']:
 tz = pytz.timezone(tzname)
 _qs = qs.filter(timezone='UTC')
 _qs =
 _qs.annotate(trunc_local_time=TruncSecond('timestamp', tzinfo=tz))
 partitions.append(_qs)

 qs1, qs2 = partitions

 result = list(qs1.union(qs2))

 for x in result:
 tz = pytz.timezone(x.timezone)
 print(x.msg)
 x.timestamp_trunc = x.timestamp.replace(microsecond=0)
 x.expected = x.timestamp_trunc.astimezone(tz)  # this is
 the working way  (but I wanted to get localization in DB layer)
 assert x.trunc_local_time == x.expected,  "Error (msg:
 '{x.msg}'): {x.trunc_local_time} != {x.expected}".format(x=x)

 }}}

 {{{
 Failure
 Traceback (most recent call last):
   File "/home/jurgis/dev/new/tableair/sync_tableair-
 cloud/ta/api/booking/tests/test_endpoints.py", line 1107, in test_demo_bug
 assert x.trunc_local_time == x.expected,  "Error (msg: '{x.msg}'):
 {x.trunc_local_time} != {x.expected}".format(x=x)
 AssertionError: Error (msg: 'bla'): 2016-12-31 16:00:00+00:00 !=
 2017-01-01 00:00:00+00:00}}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/046.7e3964351c1456efeb603e7a1f5f0ed2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.