submission publish_date doesn't consider dst

[woodz-]

Hi,
I am on UTC+1 (MEZ) timezone. I was filing a test nsl between 00:00 and 01:00 am. During this period of time the day of the archive url was 1 day past the day of the Submission object.
The dst calculation seems to be correct (this time without dst, winter time +00:00):
2019-03-15 00:00:14+00:00
But the hour is too low by 1 and thus the day gets also too low by one during 00:00 and 01:00 am.
The timestamp given should read as: 2019-03-15 01:00:14+00:00

Curios because the day gets calculated from the model's get_absolute_url(self) method of the Submission object, which uses:

publish_date = models.DateTimeField( verbose_name=_('publication date'), blank=True, null=True, default=now, db_index=True )

The archive template makes use of this method and the Submission object holds it.
So from where do we get the deviation of 1 day for 1 hour?

[dokterbob]

Perhaps a Django bug? AFAIK, we didn’t implement more than the absolute minimum in the archive views.

[woodz-]

Can we be sure, that everything to and from the DB is handled as UTC? I found one place where the timezone is requested from settings and a python datetime object gets mixed in:

def _make_date_lookup_arg(self, value):
"""
Convert a date into a datetime when the date field is a DateTimeField.

When time zone support is enabled,date is assumed to be in the
default time zone, so that displayed items are consistent with the URL.

Related discussion:
https://github.com/dokterbob/django-newsletter/issues/74
"""
value = datetime.datetime.combine(value, datetime.time.min)
if settings.USE_TZ:
value = timezone.make_aware(value, timezone.get_default_timezone())
return value

but I could not find, where this method gets called. Can someone give a hand here? Does it hang around idle? Probably related: #74

[dokterbob]

Seems dead code to me. But perhaps it shouldn’t be dead and that’s the issue. Did you look at the linked GH issue?

[woodz-]

Yes, most changes are for newsletter/tests/test_web.py and the method _make_date_lookup_arg came in with that issue (in views.py). But no call from anywhere as I can see. From where should it be called?
In respect to the comment: Convert a date into a datetime when the date field is a DateTimeField
it sounds this method shall be made a kind of a property and be a wrapper for DateTimeField of django model.
For me it's still hard to believe that DateTimeField isn't able to handle all that stuff by itself. It should be UTC compliant and if USE_TZ is set in settings, everything should run. Otherwise any django application would need such a hand made wrapping if it makes use of DateTimeField(s) in the model. Is it serious?
looking onto the linked issue more specific: which inherits from DateDetailView. DateDetailView is a django built in, so one can fulminate a django bug.