Django TIME_ZONE definition ignored by time.tzname - django

I need use Timezone in a Django app.
I defined in settings.py UTC timezone :
TIME_ZONE = 'UTC'
I put the following code in a view :
import time
print(time.tzname)
But it displays me :
('Paris, Madrid')
Do you know how to define timezone in all the Django app ?

Your settings are fine. time.tzname just tells you what Python thinks the local system time zone is, it has nothing to do with your Django settings.
If you use django.utils.timezone.get_default_timezone_name() you should see UTC as you expect.

Related

Store Datetime field in localtime in Django

I use Django 3 with postgresql. USE_TZ is False and TIME_ZONE is 'Asia/Baku'.
django.utils.timezone.now() correctly return Baku localtime, but all DateTimeFields with auto_now_add save datetime in UTC in database. I want to use localtime everywhere in my app.
edit: I use ubuntu server and timezone is set on Baku

Timezone is UTC infact of changing it in settings.py file

My app is showing the timezone.now() as UTC time when I see it in Heroku scheduler. Also I built a custom manage.py command to test it but it still shows UTC time.
Here is my settings.py
LANGUAGE_CODE = 'en-us'
TIME_ZONE = 'Asia/Kolkata'
USE_I18N = True
USE_L10N = True
USE_TZ = True
Here is my personalied manage.py command
managemet/commaands/abhiwaqt.py
from django.core.management.base import BaseCommand, CommandError
from django.apps import apps
from Directory.utils import *
class Command(BaseCommand):
help="Refresh models and its fields."
def handle(self,*args, **options):
try:
print(timezone.now())
except:
raise CommandError("Something went wrong")
Infact of setting TIME_ZONE='Asia/Kolkata' I am getting this issue.
It is probably good practice to keep your back end using UTC so everything is uniform and handles daylight savings and you simply handle the changes when displaying to the user in templates or views. If you want timezone support (since it is disabled by default) use the setting USE_TZ = True. Take a look at the docs for more in depth explanation on this topic.enter link description here

Get Timezone to take effect

I am going through the Django tutorial.
I thought the TIME_ZONE in settings.py was of form 'UTC-5', but it isn't.
I replaced it with 'America/Chicago'
However, when I do:
python manage.py shell
from django.utils import timezone
timezone.now()
I get 'UTC'
How do I get the timezone to take effect?
It can be confusing. If you run the code below, you will see that it is set, but it won't output as you expect:
from django.utils import timezone
timezone.get_current_timezone() # Should be 'America/Chicago'
timezone.now() # should show UTC
If you want it to output in the shell with your set timezone, use timezone.localtime()
from django.utils import timezone
timezone.localtime()

How do I get dates to display using my settings TIME_ZONE

I'm using Django and Python 3.7. I have the following set in my settings file ...
LANGUAGE_CODE = 'en-us'
TIME_ZONE = 'America/Chicago'
USE_I18N = True
USE_L10N = True
USE_TZ = True
I would like for all dates to display using the default time zone I have above. However, when I print out fields like
self.created_on.ctime()
in which "created_on" maps to a PostGres DATETIME field, the date is printed out using a UTC timezone. How can I get this to display using the time zone I have?
TIME_ZONE is a session parameter. Find out more here
and here
from datetime import datetime
from pytz import timezone
self.created_on.astimezone(timezone('America/Chicago'))
looks like you can use the django.utils.timezone.localtime
from django.utils.timezone import localtime
localtime(self.created_on).ctime()

Timezone It works locally but not in pythonanywhere (DJango)

I have a queryset to list today's sales
from django.utils import timezone
class VentaToday(ListView):
queryset = Venta.objects.filter(fecha=timezone.now()).order_by('-id')
template_name = 'venta/venta_today.html'
In local, this works correctly but in production (Pythonanywhere) the sales of the previous day keep appearing. To fix it, I have to go to the pythonanywhere panel and click on the ** reload ** button to solve the problem.
I changed the server time:
Image of server time
Configuration of the django project:
LANGUAGE_CODE = 'es-pe'
TIME_ZONE = 'America/Lima'
USE_I18N = True
USE_L10N = True
USE_TZ = True
Is it a server cache problem? or something am I doing wrong?
UPDATE
config WSGI:
# +++++++++++ DJANGO +++++++++++
# To use your own django app use code like this:
import os
import sys
os.environ["TZ"] = "America/Lima"
#
## assuming your django settings file is at '/home/dnicosventas/mysite/mysite/settings.py'
## and your manage.py is is at '/home/dnicosventas/mysite/manage.py'
path = '/home/dnicosventas/dnicos-ventas'
if path not in sys.path:
sys.path.append(path)
#
os.environ['DJANGO_SETTINGS_MODULE'] = 'DnicosVentas.settings'
#
## then, for django >=1.5:
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()
## or, for older django <=1.4
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
and my console:
export TZ="/usr/share/zoneinfo/America/Lima"
Even so, after 12 a.m., yesterday's sales keep appearing until I click on the reload button in the pythonanywhere panel.
Views.py:
class VentaToday(ListView):
today = datetime.now(pytz.timezone('America/Lima'))
queryset = Venta.objects.filter(fecha=today).order_by('-id')
template_name = 'venta/venta_today.html'
Image of the reload button
Solution by Giles Thomas:
class VentaToday(ListView):
template_name = 'venta/venta_today.html'
def get_queryset(self):
return Venta.objects.filter(fecha=datetime.now(pytz.timezone('America/Lima'))).order_by('-id')
TLDR: I had the same issue. I fixed it by changing TIME_ZONE='' to TIME_ZONE='UTC', in the settings.py file in project folder of pythonanywhere.
Python by default uses pytz.timezone(settings.TIME_ZONE), to initiate the time zone of the webapp, and since by default pythonanywhere doesnt initiate this variable, leaving it to the end user to do it, as per their requirements. So initiate your TIME_ZONE, as per your needs, which may do the trick.
You could also try looking in your project log files, for more information on this.