Re: [Django] #29754: Trunc() doesn't handle NonExistentTimeError/AmbiguousTimeError

2018-09-13 Thread Django
#29754: Trunc() doesn't handle NonExistentTimeError/AmbiguousTimeError
-+-
 Reporter:  Alexander Holmbäck   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  pytz, Trunc()| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 The `AmbiguousTimeError` case could be worked around by adding a
 `Trunc(is_dst=None)` optional argument that would be passed down to
 `localize`. That would make the API a bit more usable when tzinfo is
 provided and you know what you're after.

 I'm afraid there isn't much that can be done for `NonExistentTimeError`
 though.

-- 
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/066.bf5f4962af740d27bd6d170272ae5e35%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #29755: Infinite migrations created after removing Meta.default_related_name

2018-09-13 Thread Django
#29755: Infinite migrations created after removing Meta.default_related_name
-+-
 Reporter:  Aamir Rind   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  migrations,unlimited,infinite,makemigrations|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * owner:  nobody => Simon Charette
 * status:  new => assigned
 * has_patch:  0 => 1


Comment:

 It was a simple matter of adding the option to
 `AlterModelOptions.ALTER_OPTION_KEYS`

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

-- 
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.9c8a60089039d995c932b8ead981d915%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #29721: Migrations are not applied atomically

2018-09-13 Thread Django
#29721: Migrations are not applied atomically
+
 Reporter:  Gavin Wahl  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  2.1
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by Tim Graham):

 * 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/067.0a83c78035b708a007a4749380ba6534%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #29754: Trunc() doesn't handle NonExistentTimeError/AmbiguousTimeError

2018-09-13 Thread Django
#29754: Trunc() doesn't handle NonExistentTimeError/AmbiguousTimeError
-+-
 Reporter:  Alexander Holmbäck   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  pytz, Trunc()| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 I don't have much expertise but reading the documentation, it sounds like
 you may be [https://docs.djangoproject.com/en/dev/topics/i18n/timezones
 /#interpretation-of-naive-datetime-objects creating invalid data]. Django
 converts datetimes when `USE_TZ` is activate, I don't think it can hide
 that exception. Did you carefully review the pytz documentation which
 states, "Unfortunately using the tzinfo argument of the standard datetime
 constructors ‘’does not work’’ with pytz for many timezones."

-- 
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/066.23fec88e135e0b5c1eb44d2aa8c0898f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #29755: Infinite migrations created after removing Meta.default_related_name (was: Infinite Django Migrations)

2018-09-13 Thread Django
#29755: Infinite migrations created after removing Meta.default_related_name
-+-
 Reporter:  Aamir Rind   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  migrations,unlimited,infinite,makemigrations|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * component:  Core (Management commands) => Migrations
 * version:  2.1 => 1.11
 * stage:  Unreviewed => Accepted


Comment:

 Bug report seems to be against Django 1.11 but I verified that it affects
 master as of today (1b1f64ee5a78cc217fead52cbae23114502cf564).

-- 
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.aa0767b811278fec961f76fe1e838821%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #29755: Infinite Django Migrations

2018-09-13 Thread Django
#29755: Infinite Django Migrations
-+-
   Reporter:  Aamir  |  Owner:  nobody
  Rind   |
   Type:  Bug| Status:  new
  Component:  Core   |Version:  2.1
  (Management commands)  |   Keywords:
   Severity:  Normal |  
migrations,unlimited,infinite,makemigrations
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Consider there exists following models:


 {{{
 from django.db import models


 class Parent(models.Model):
 name = models.CharField(max_length=50)


 class Child(models.Model):
 parent = models.ForeignKey('polls.Parent')

 class Meta:
 default_related_name = 'children'
 ordering = ('id', )
 }}}


 - Run `makemigrations` command this will create `0001_initial.py`
 migration.
 - Now go to `models.py` and remove `default_related_name` from `Child`
 model.
 - Run `makemigrations` multiple times and it will create same migration
 again and again.

 I have created a project to reproduce this issue:
 https://github.com/intellisense/django-infinite-migrations

-- 
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/055.b8c8160d625cc565952dfbfcc6e4d82f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #29754: Trunc() doesn't handle NonExistentTimeError/AmbiguousTimeError (was: Trunc() doesn't handle NonExistingTimeError/AmbiguousTimeError)

2018-09-13 Thread Django
#29754: Trunc() doesn't handle NonExistentTimeError/AmbiguousTimeError
-+-
 Reporter:  Alexander Holmbäck   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  pytz, Trunc()| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Alexander Holmbäck:

Old description:

> When `Trunc()` truncates to a nonexisting or ambiguous datetime, the
> exception raised by pytz remains unhandled. The expected behavior would,
> IMO, be to use naive datetimes for truncated dates, or adjust to closest
> existing non-ambiguous datetime.
>
> This test for example:
> {{{#!python
> import datetime
> import pytz
>
> from django.db.models.functions import Trunc
> from django.test import TestCase
> from django.utils import timezone
>
> from .models import Log
>

> class TestTruncateToNonExistingTime(TestCase):
>
> def test_truncate_to_dst_ends_stockholm(self):
> tzinfo = pytz.timezone('Europe/Stockholm')
> timestamp = datetime.datetime(2018, 10, 28, 2, tzinfo=tzinfo)
> Log.objects.create(timestamp=timestamp)
> logs = Log.objects.annotate(day=Trunc('timestamp', 'hour')).all()
>
> timezone.activate(tzinfo)
> self.assertEqual(logs[0].day.day, 28)
> }}}
>
> Results in the following error:
> {{{
> ==
> ERROR: test_truncate_to_dst_ends_stockholm
> (trunc.tests.TestTruncateToNonExistingTime)
> --
> Traceback (most recent call last):
>   File "/home/alex/tickets/trunc/tests.py", line 47, in
> test_truncate_to_dst_ends_stockholm
> self.assertEqual(logs[0].day.day, 28)
>   File "/home/alex/django/django/db/models/query.py", line 303, in
> __getitem__
> qs._fetch_all()
>   File "/home/alex/django/django/db/models/query.py", line 1190, in
> _fetch_all
> self._result_cache = list(self._iterable_class(self))
>   File "/home/alex/django/django/db/models/query.py", line 64, in
> __iter__
> for row in compiler.results_iter(results):
>   File "/home/alex/django/django/db/models/sql/compiler.py", line 1013,
> in apply_converters
> value = converter(value, expression, connection)
>   File "/home/alex/django/django/db/models/functions/datetime.py", line
> 225, in convert_value
> value = timezone.make_aware(value, self.tzinfo)
>   File "/home/alex/django/django/utils/timezone.py", line 270, in
> make_aware
> return timezone.localize(value, is_dst=is_dst)
>   File "/home/alex/.virtualenvs/djangodev/lib/python3.6/site-
> packages/pytz/tzinfo.py", line 363, in localize
> raise AmbiguousTimeError(dt)
> pytz.exceptions.AmbiguousTimeError: 2018-10-28 02:00:00
> }}}

New description:

 When `Trunc()` truncates to a nonexisting or ambiguous datetime, the
 exception raised by pytz remains unhandled. The expected behavior would,
 IMO, be to not check the validity of truncated dates.

 This test for example:
 {{{#!python
 import datetime
 import pytz

 from django.db.models.functions import Trunc
 from django.test import TestCase
 from django.utils import timezone

 from .models import Log


 class TestTruncateToInvalidTime(TestCase):

 def test_truncate_to_dst_ends_stockholm(self):
 tzinfo = pytz.timezone('Europe/Stockholm')
 timestamp = datetime.datetime(2018, 10, 28, 2, tzinfo=tzinfo)
 Log.objects.create(timestamp=timestamp)
 logs = Log.objects.annotate(day=Trunc('timestamp', 'hour')).all()

 timezone.activate(tzinfo)
 self.assertEqual(logs[0].day.day, 28)
 }}}

 Results in the following error:
 {{{
 ==
 ERROR: test_truncate_to_dst_ends_stockholm
 (trunc.tests.TestTruncateInvalidTime)
 --
 Traceback (most recent call last):
   File "/home/alex/tickets/trunc/tests.py", line 47, in
 test_truncate_to_dst_ends_stockholm
 self.assertEqual(logs[0].day.day, 28)
   File "/home/alex/django/django/db/models/query.py", line 303, in
 __getitem__
 qs._fetch_all()
   File "/home/alex/django/django/db/models/query.py", line 1190, in
 _fetch_all
 self._result_cache = list(self._iterable_class(self))
   File "/home/alex/django/django/db/models/query.py", line 64, in __iter__
 for row in 

Re: [Django] #17904: Custom permissions on proxy model no longer created

2018-09-13 Thread Django
#17904: Custom permissions on proxy model no longer created
-+-
 Reporter:  Koen Biermans|Owner:  Arthur
 |  Rio
 Type:  Bug  |   Status:  assigned
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  proxy contenttype| Triage Stage:  Accepted
  permission |
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Arthur Rio):

 * status:  new => assigned
 * owner:  nobody => Arthur Rio


Comment:

 I'm going to try to address the security concerns in a new
 [https://github.com/django/django/pull/10381 pull request].

-- 
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/063.320e903eaa456c1a5f91a304f1241124%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #29754: Trunc() doesn't handle NonExistingTimeError/AmbiguousTimeError

2018-09-13 Thread Django
#29754: Trunc() doesn't handle NonExistingTimeError/AmbiguousTimeError
-+-
   Reporter:  Alexander  |  Owner:  nobody
  Holmbäck   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  pytz, Trunc()
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When `Trunc()` truncates to a nonexisting or ambiguous datetime, the
 exception raised by pytz remains unhandled. The expected behavior would,
 IMO, be to use naive datetimes for truncated dates, or adjust to closest
 existing non-ambiguous datetime.

 This test for example:
 {{{#!python
 import datetime
 import pytz

 from django.db.models.functions import Trunc
 from django.test import TestCase
 from django.utils import timezone

 from .models import Log


 class TestTruncateToNonExistingTime(TestCase):

 def test_truncate_to_dst_ends_stockholm(self):
 tzinfo = pytz.timezone('Europe/Stockholm')
 timestamp = datetime.datetime(2018, 10, 28, 2, tzinfo=tzinfo)
 Log.objects.create(timestamp=timestamp)
 logs = Log.objects.annotate(day=Trunc('timestamp', 'hour')).all()

 timezone.activate(tzinfo)
 self.assertEqual(logs[0].day.day, 28)
 }}}

 Results in the following error:
 {{{
 ==
 ERROR: test_truncate_to_dst_ends_stockholm
 (trunc.tests.TestTruncateToNonExistingTime)
 --
 Traceback (most recent call last):
   File "/home/alex/tickets/trunc/tests.py", line 47, in
 test_truncate_to_dst_ends_stockholm
 self.assertEqual(logs[0].day.day, 28)
   File "/home/alex/django/django/db/models/query.py", line 303, in
 __getitem__
 qs._fetch_all()
   File "/home/alex/django/django/db/models/query.py", line 1190, in
 _fetch_all
 self._result_cache = list(self._iterable_class(self))
   File "/home/alex/django/django/db/models/query.py", line 64, in __iter__
 for row in compiler.results_iter(results):
   File "/home/alex/django/django/db/models/sql/compiler.py", line 1013, in
 apply_converters
 value = converter(value, expression, connection)
   File "/home/alex/django/django/db/models/functions/datetime.py", line
 225, in convert_value
 value = timezone.make_aware(value, self.tzinfo)
   File "/home/alex/django/django/utils/timezone.py", line 270, in
 make_aware
 return timezone.localize(value, is_dst=is_dst)
   File "/home/alex/.virtualenvs/djangodev/lib/python3.6/site-
 packages/pytz/tzinfo.py", line 363, in localize
 raise AmbiguousTimeError(dt)
 pytz.exceptions.AmbiguousTimeError: 2018-10-28 02: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/051.e0a2081e6da704587b06d7512bf6225b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #897: Bi-Directional ManyToMany in Admin

2018-09-13 Thread Django
#897: Bi-Directional ManyToMany in Admin
---+
 Reporter:  anonymous  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Ramiro Morales):

 Isn't this use case covered by this admin functionality?:
 https://docs.djangoproject.com/en/2.1/ref/contrib/admin/#working-with-
 many-to-many-models

-- 
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.3924bdc7e01c17d8e36fc91186e7e027%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #14357: Prevent inappropriate order-based grouping on values+annotate queries

2018-09-13 Thread Django
#14357: Prevent inappropriate order-based grouping on values+annotate queries
-+-
 Reporter:  Martin Chase |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"1b1f64ee5a78cc217fead52cbae23114502cf564" 1b1f64ee]:
 {{{
 #!CommitTicketReference repository=""
 revision="1b1f64ee5a78cc217fead52cbae23114502cf564"
 Refs #14357 -- Deprecated Meta.ordering affecting GROUP BY queries.

 Thanks Ramiro Morales for contributing to the patch.
 }}}

-- 
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.ba3d0938bdc32df26cbc8246aa1e46bb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #29711: Add system check to ensure uniqueness of admin actions' __name__.

2018-09-13 Thread Django
#29711: Add system check to ensure uniqueness of admin actions' __name__.
-+-
 Reporter:  Przemysław   |Owner:
  Buczkowski |  Przemysław Buczkowski
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Przemysław Buczkowski):

 * has_patch:  0 => 1


Comment:

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

-- 
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/065.ff54dbb4477efd937e258b37ea66684b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #29711: Add system check to ensure uniqueness of admin actions' __name__.

2018-09-13 Thread Django
#29711: Add system check to ensure uniqueness of admin actions' __name__.
-+-
 Reporter:  Przemysław   |Owner:
  Buczkowski |  Przemysław Buczkowski
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Przemysław Buczkowski):

 Just a quick heads-up that I'll be getting down to it, I'm just reading on
 [https://docs.djangoproject.com/en/dev/internals/contributing/writing-code
 /submitting-patches/ this] and friends in before :)

-- 
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/065.94c1fff17568f0e0d6ea5d5335da2e56%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #29547: Support for partial/filtered indexes

2018-09-13 Thread Django
#29547: Support for partial/filtered indexes
-+-
 Reporter:  Mads Jensen  |Owner:  Mads
 |  Jensen
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  db-indexes   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mads Jensen):

 * owner:  nobody => Mads Jensen
 * needs_better_patch:  1 => 0
 * status:  new => assigned


-- 
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/068.1e97e2d3e25c3d4bc34d1b132fea1278%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #29738: Django can't serialize DateTimeTZRange(lower=None, upper=None, bounds='[)')

2018-09-13 Thread Django
#29738: Django can't serialize DateTimeTZRange(lower=None, upper=None, 
bounds='[)')
-+-
 Reporter:  Graham Mayer |Owner:  Can
 |  Sarıgöl
 Type:  Bug  |   Status:  assigned
Component:  contrib.postgres |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  rangefield   | Triage Stage:  Accepted
  postgresql psycopg2 migrations |
  removed|
Has patch:  0|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Can Sarıgöl):

 * owner:  nobody => Can Sarıgöl
 * status:  new => assigned


-- 
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/069.7a7d19fe9682e09a324d0e4e9ee01123%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.