Time Zone Issue in Postorius
Hello,
I'm encountering an error that sounds similar to this previous thread:
https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
I've tried setting my TIME_ZONE to 'UTC' in my settings.py and settings_local.py files (and restarting Mailman), but when I check the datetime for a held message in Postorius, the datetime seems to be pushed +8 hours unexpectedly.
My Postorius account time zone is set to "US/Pacific".
As a workaround, I might be able to find a "wrong" time zone that would possibly reduce the unintentional additional hours difference and show the "correct" time zone in Postorius for the "Held Messages" page, but I don't think this is the right way to fix the issue.
I think I've tried setting the TIME_ZONE setting to "America/Los_Angeles" in my settings.py file in place of 'UTC' in the past, but the result was still different than expected.
Does anyone know if there are other places besides the mailman settings.py and settings_local.py files where something needs to be set so that I don't get an unintentional extra +8 hours of time difference when looking at messages on the "Held Messages" page of a mailing list?
Thank you, Andrew
On 2/4/22 09:48, Andy Summers wrote:
Hello,
I'm encountering an error that sounds similar to this previous thread:
https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
I've tried setting my TIME_ZONE to 'UTC' in my settings.py and settings_local.py files (and restarting Mailman), but when I check the datetime for a held message in Postorius, the datetime seems to be pushed +8 hours unexpectedly.
My Postorius account time zone is set to "US/Pacific".
The appropriate setting for Django is always TIME_ZONE = 'UTC'because
the time passed from Mailman core is a naive datetime.datetime object
and is actually UTC. This should then display the time in your account
timezone since Postorius 1.3.4. See
https://gitlab.com/mailman/postorius/-/merge_requests/531
If this isn't working in Postorius >=1.3.4, it's a Django issue.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 2/4/22 10:29 AM, Mark Sapiro wrote:
My Postorius account time zone is set to "US/Pacific".
The appropriate setting for Django is always
TIME_ZONE = 'UTC'because the time passed from Mailman core is a naive datetime.datetime object and is actually UTC.
Could use clarification on this. Are you referring to the settings.py file, or something else?
Asking because my settings.py currently has:
# Django time zones USE_TZ = True TIME_ZONE = 'America/Los_Angeles'
and list timestamps appear to work OK both in Hyperkitty and as received by members' mail clients.
This is with postorius 1.3.6 and Django 3.0.14.
Is this setting incorrect?
Thanks
dn
On 2/7/22 21:18, David Newman wrote:
On 2/4/22 10:29 AM, Mark Sapiro wrote:
The appropriate setting for Django is always
TIME_ZONE = 'UTC'because the time passed from Mailman core is a naive datetime.datetime object and is actually UTC.Could use clarification on this. Are you referring to the settings.py file, or something else?
Settings.py
Asking because my settings.py currently has:
# Django time zones USE_TZ = True TIME_ZONE = 'America/Los_Angeles'
It should be TIME_ZONE = 'UTC'
Times passed from Mailman core are naive times, I.e. they don't have time zone info, but they are in UTC. Thus for Django to get the correct time with time zone you need USE_TZ = True (without that, Django will throw an exception about naive times) and the TIME_ZONE to apply is UTC.
With those settings, Django has the correct time zone aware times.
and list timestamps appear to work OK both in Hyperkitty and as received by members' mail clients.
Mail sent to list members is not at all affected by this. That involves Mailman core only. Also, time stamps on posts in HyperKitty come from Date: headers or Django internal times. Where you see this manifested is for example when looking at a held message in Postorius and seeing the hold time. which is a time stamp generated by Mailman core.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
-----Oprindelig meddelelse----- Fra: Mark Sapiro <mark@msapiro.net> Sendt: 8. februar 2022 07:48 Til: mailman-users@mailman3.org Emne: [MM3-users] Re: Time Zone Issue in Postorius
It should be TIME_ZONE = 'UTC'
Times passed from Mailman core are naive times, I.e. they don't have time zone info, but they are in UTC. Thus for Django to get the correct time with time zone you need USE_TZ = True (without that, Django will throw an exception about naive times) and the TIME_ZONE to apply is UTC.
As https://stackoverflow.com/questions/29311354/how-to-set-the-timezone-in-djan... seems to say otherwise ("You can use TIME_ZONE = 'Europe/Istanbul'"), to make sure, am I right to understand it as for Mailman, Danish time should be stated as "TIME_ZONE = 'UTC+1' " with use of "USE_TZ = True"?
/Henrik Rasmussen
Henrik Rasmussen writes:
Fra: Mark Sapiro <mark@msapiro.net>
It should be TIME_ZONE = 'UTC'
Times passed from Mailman core are naive times, I.e. they don't have time zone info, but they are in UTC.
Mark is saying that Mailman core converts to UTC. All times that come out of Mailman core in the relevant API are UTC.
As stackoverflow.com/questions/29311354/how-to-set-the-timezone-in-django seems to say otherwise ("You can use TIME_ZONE = 'Europe/Istanbul'"), to make sure, am I right to understand it as for Mailman, Danish time should be stated as "TIME_ZONE = 'UTC+1' " with use of "USE_TZ = True"?
No, USE_TZ=True means "hey Django, you need to add a time zone to this datetime." And you use TIME_ZONE=UTC (exactly), because this variable is *not* the local time zone, it's the time zone that Postorius tells Django to add to datetime objects that don't carry their timezone with them. There is a setting somewhere else that tells Django what time zone should be used for I/O.
Steve
participants (5)
-
Andy Summers -
David Newman -
Henrik Rasmussen -
Mark Sapiro -
Stephen J. Turnbull