När stöd för tidszoner är aktiverat lagrar Django datetime-information i UTC i databasen, använder tidszonmedvetna datetime-objekt internt och konverterar dem till slutanvändarens tidszon i formulär. Mallar kommer att använda standardtidszonen, men detta kan uppdateras till slutanvändarens tidszon genom användning av filter och taggar.
\nDetta är praktiskt om dina användare bor i mer än en tidszon och du vill visa datatidsinformation enligt varje användares väggklocka.
\nÄven om din webbplats bara är tillgänglig i en enda tidszon är det ändå bra att lagra data i UTC i databasen. Det främsta skälet är sommartid (DST). Många länder har ett system med sommartid, där klockorna ställs fram på våren och tillbaka på hösten. Om du arbetar med lokal tid kommer du sannolikt att stöta på fel två gånger om året, när övergångarna sker. Det här spelar förmodligen ingen roll för din blogg, men det är ett problem om du överfakturerar eller underfakturerar dina kunder med en timme, två gånger om året, varje år. Lösningen på det här problemet är att använda UTC i koden och endast använda lokal tid när du interagerar med slutanvändare.
\nStöd för tidszoner är aktiverat som standard. För att inaktivera det, ange USE_TZ = False i din inställningsfil.
Tidszonsstöd använder zoneinfo, som är en del av Pythons standardbibliotek från Python 3.9.
Om du brottas med ett särskilt problem kan du börja med time zone FAQ.
\nPythons datetime.datetime-objekt har ett tzinfo-attribut som kan användas för att lagra tidszoninformation, representerad som en instans av en underklass av datetime.tzinfo. När detta attribut är inställt och beskriver en förskjutning, är ett datetime-objekt medvetet. Annars är det naive.
Du kan använda is_aware() och is_naive() för att avgöra om datatider är medvetna eller naiva.
När stödet för tidszoner är avaktiverat använder Django naiva datetime-objekt i lokal tid. Detta är tillräckligt för många användningsfall. I det här läget skulle du skriva: för att få aktuell tid:
\nimport datetime\n\nnow = datetime.datetime.now()\nNär stöd för tidszoner är aktiverat (USE_TZ=True) använder Django tidszonsmedvetna datetime-objekt. Om din kod skapar datetime-objekt bör de också vara medvetna. I det här läget blir exemplet ovan:
from django.utils import timezone\n\nnow = timezone.now()\nNär USE_TZ är True, accepterar Django fortfarande naiva datetime-objekt, för att bevara bakåtkompatibilitet. När databaslagret tar emot ett sådant försöker det göra det medvetet genom att tolka det i default time zone och ger en varning.
Under DST-övergångar finns det tyvärr vissa datatider som inte existerar eller som är tvetydiga. Det är därför du alltid bör skapa medvetna datetime-objekt när stöd för tidszoner är aktiverat. (Se Using ZoneInfo section of the zoneinfo docs för exempel på användning av attributet fold för att ange den förskjutning som ska gälla för en datatid under en övergång till sommartid)
I praktiken är detta sällan ett problem. Django ger dig medvetna datetime-objekt i modellerna och formulären, och oftast skapas nya datetime-objekt från befintliga genom timedelta-aritmetik. Den enda datatid som ofta skapas i applikationskoden är den aktuella tiden, och timezone.now() gör automatiskt rätt sak.
Standardtidszonen är den tidszon som definieras av inställningen TIME_ZONE.
Den aktuella tidszonen är den tidszon som används för rendering.
\nDu bör ställa in den aktuella tidszonen till slutanvändarens faktiska tidszon med activate(). Annars används standardtidszonen.
Den aktuella tidszonen är motsvarigheten till den aktuella locale för översättningar. Det finns dock ingen motsvarighet till HTTP-headern Accept-Language som Django kan använda för att automatiskt bestämma användarens tidszon. Istället tillhandahåller Django funktioner för val av tidszon. Använd dem för att bygga den logik för val av tidszon som är vettig för dig.
De flesta webbplatser som bryr sig om tidszoner frågar användarna i vilken tidszon de bor och lagrar denna information i användarens profil. För anonyma användare använder de tidszonen för sin primära målgrupp eller UTC. zoneinfo.available_timezones() ger en uppsättning tillgängliga tidszoner som du kan använda för att bygga en karta från sannolika platser till tidszoner.
Här är ett exempel som lagrar den aktuella tidszonen i sessionen. (Det hoppar över felhanteringen helt för enkelhetens skull)
\nLägg till följande middleware i MIDDLEWARE:
import zoneinfo\n\nfrom django.utils import timezone\n\n\nclass TimezoneMiddleware:\n def __init__(self, get_response):\n self.get_response = get_response\n\n def __call__(self, request):\n tzname = request.session.get("django_timezone")\n if tzname:\n timezone.activate(zoneinfo.ZoneInfo(tzname))\n else:\n timezone.deactivate()\n return self.get_response(request)\nSkapa en vy som kan ställa in aktuell tidszon:
\nfrom django.shortcuts import redirect, render\n\n# Prepare a map of common locations to timezone choices you wish to offer.\ncommon_timezones = {\n "London": "Europe/London",\n "Paris": "Europe/Paris",\n "New York": "America/New_York",\n}\n\n\ndef set_timezone(request):\n if request.method == "POST":\n request.session["django_timezone"] = request.POST["timezone"]\n return redirect("/")\n else:\n return render(request, "template.html", {"timezones": common_timezones})\nInkludera ett formulär i template.html som kommer att POST till denna vy:
{% load tz %}\n{% get_current_timezone as TIME_ZONE %}\n<form action="{% url 'set_timezone' %}" method="POST">\n {% csrf_token %}\n <label for="timezone">Time zone:</label>\n <select name="timezone">\n {% for city, tz in timezones.items %}\n <option value="{{ tz }}"{% if tz == TIME_ZONE %} selected{% endif %}>{{ city }}</option>\n {% endfor %}\n </select>\n <input type="submit" value="Set">\n</form>\nNär du aktiverar stöd för tidszoner tolkar Django datatider som anges i formulär i aktuell tidszon och returnerar medvetna datatidsobjekt i cleaned_data.
Konverterade datumtider som inte existerar eller som är tvetydiga eftersom de faller i en DST-övergång kommer att rapporteras som ogiltiga värden.
\nNär du aktiverar stöd för tidszoner konverterar Django medvetna datetime-objekt till aktuell tidszon när de återges i mallar. Detta beter sig väldigt mycket som format localization.
\n\nOmvandling till lokal tid är inte alltid lämplig - du kanske genererar utdata för datorer snarare än för människor. Följande filter och taggar, som tillhandahålls av malltaggbiblioteket tz, gör att du kan kontrollera tidszonskonverteringarna.
Dessa filter accepterar både medvetna och naiva datatider. För konverteringsändamål antar de att naiva datatider är i standardtidszonen. De returnerar alltid medvetna datatider.
\nlokaltidLink to this heading#Tvingar fram konvertering av ett enskilt värde till aktuell tidszon.
\nTill exempel:
\n{% load tz %}\n\n{{ value|localtime }}\nutcLink to this heading#Tvingar fram konvertering av ett enskilt värde till UTC.
\nTill exempel:
\n{% load tz %}\n\n{{ value|utc }}\ntidszonLink to this heading#Tvingar fram konvertering av ett enskilt värde till en godtycklig tidszon.
\nArgumentet måste vara en instans av en tzinfo-underklass eller ett tidszonnamn.
Till exempel:
\n{% load tz %}\n\n{{ value|timezone:"Europe/Paris" }}\nSå här gör du för att migrera ett projekt som startades innan Django stödde tidszoner.
\nPostgreSQL-backend lagrar datatider som `` tidsstämpel med tidszon``. I praktiken betyder det att den konverterar datatider från anslutningens tidszon till UTC vid lagring och från UTC till anslutningens tidszon vid hämtning.
\nSom en följd av detta, om du använder PostgreSQL, kan du växla mellan USE_TZ = False och USE_TZ = True fritt. Databasanslutningens tidszon kommer att ställas in till DATABASE-TIME_ZONE respektive UTC, så att Django får korrekta datatider i alla fall. Du behöver inte utföra några datakonverteringar.
Andra backends lagrar datatider utan tidszoninformation. Om du byter från USE_TZ = False till USE_TZ = True, måste du konvertera dina data från lokal tid till UTC - vilket inte är deterministiskt om din lokala tid har DST.
Det första steget är att lägga till USE_TZ = True i din inställningsfil. Vid denna punkt bör saker och ting mestadels fungera. Om du skapar naiva datetime-objekt i din kod, gör Django dem medvetna när det behövs.
Dessa konverteringar kan dock misslyckas vid DST-övergångar, vilket innebär att du inte får alla fördelar med tidszonsstöd ännu. Dessutom kommer du sannolikt att stöta på några problem eftersom det är omöjligt att jämföra en naiv datatid med en medveten datatid. Eftersom Django nu ger dig medvetna datatider kommer du att få undantag när du jämför en datatid som kommer från en modell eller ett formulär med en naiv datatid som du har skapat i din kod.
\nSå det andra steget är att omarbeta din kod varhelst du instansierar datetime-objekt för att göra dem medvetna. Detta kan göras stegvis. django.utils.timezone definierar några praktiska hjälpmedel för kompatibilitetskod: now(), is_aware(), is_naive(), make_aware(), och make_naive().
Slutligen, för att hjälpa dig att hitta kod som behöver uppgraderas, ger Django en varning när du försöker spara en naiv datatid i databasen:
\nRuntimeWarning: DateTimeField ModelName.field_name received a naive\ndatetime (2012-01-01 00:00:00) while time zone support is active.\nUnder utvecklingsarbetet kan du omvandla sådana varningar till undantag och få en spårning genom att lägga till följande i din inställningsfil:
\nimport warnings\n\nwarnings.filterwarnings(\n "error",\n r"DateTimeField .* received a naive datetime",\n RuntimeWarning,\n r"django\\.db\\.models\\.fields",\n)\nVid serialisering av en medveten datatid inkluderas UTC-offset, så här:
\n"2011-09-01T13:20:30+03:00"\nMedan det för en naiv datatid inte är:
\n"2011-09-01T13:20:30"\nFör modeller med DateTimeField gör denna skillnad det omöjligt att skriva en fixtur som fungerar både med och utan stöd för tidszoner.
Fixturer som genererats med USE_TZ = False, eller före Django 1.4, använder det ”naiva” formatet. Om ditt projekt innehåller sådana fixturer kommer du att se RuntimeWarning när du laddar dem efter att du har aktiverat stöd för tidszoner. För att bli av med varningarna måste du konvertera dina fixturer till ”aware”-formatet.
Du kan regenerera fixturer med loaddata och sedan dumpdata. Eller, om de är tillräckligt små, kan du redigera dem för att lägga till UTC-offset som matchar din TIME_ZONE till varje serialiserad datatid.
Jag behöver inte flera tidszoner. Ska jag aktivera stöd för tidszoner?
\nJa, det stämmer. När stöd för tidszoner är aktiverat använder Django en mer exakt modell av lokal tid. Detta skyddar dig från subtila och icke reproducerbara buggar kring övergångar till sommartid (DST).
\nNär du aktiverar stöd för tidszoner kommer du att stöta på vissa fel eftersom du använder naiva datatider där Django förväntar sig medvetna datatider. Sådana fel dyker upp när man kör tester. Du kommer snabbt att lära dig hur du undviker ogiltiga operationer.
\nÅ andra sidan är buggar som orsakas av avsaknad av stöd för tidszoner mycket svårare att förebygga, diagnostisera och åtgärda. Allt som involverar schemalagda uppgifter eller datatidsaritmetik är en kandidat för subtila buggar som bara kommer att bita dig en eller två gånger om året.
\nAv dessa skäl är stöd för tidszoner aktiverat som standard i nya projekt, och du bör behålla det om du inte har en mycket god anledning att inte göra det.
\nJag har aktiverat tidszonsstöd. Är jag säker?
\nJa, kanske det. Du är bättre skyddad från DST-relaterade buggar, men du kan fortfarande skjuta dig själv i foten genom att slarvigt förvandla naiva datatider till medvetna datatider och vice versa.
\nOm din applikation ansluter till andra system - t.ex. om den frågar en webbtjänst - måste du se till att datatiderna är korrekt angivna. För att överföra datatider på ett säkert sätt bör deras representation inkludera UTC-offset, eller så bör deras värden vara i UTC (eller båda!).
\nSlutligen innehåller vårt kalendersystem intressanta undantagsfall. Till exempel kan man inte alltid subtrahera ett år direkt från ett givet datum:
\n>>> import datetime\n>>> def one_year_before(value): # Wrong example.\n... return value.replace(year=value.year - 1)\n...\n>>> one_year_before(datetime.datetime(2012, 3, 1, 10, 0))\ndatetime.datetime(2011, 3, 1, 10, 0)\n>>> one_year_before(datetime.datetime(2012, 2, 29, 10, 0))\nTraceback (most recent call last):\n...\nValueError: day is out of range for month\nFör att implementera en sådan funktion korrekt måste du bestämma om 2012-02-29 minus ett år är 2011-02-28 eller 2011-03-01, vilket beror på dina affärskrav.
\nHur interagerar jag med en databas som lagrar datatider i lokal tid?
\nStäll in alternativet TIME_ZONE till lämplig tidszon för den här databasen i inställningen DATABASES.
Detta är användbart för att ansluta till en databas som inte stöder tidszoner och som inte hanteras av Django när USE_TZ är True.
Mitt program kraschar med TypeError: can't compare offset-naive and offset-aware datetimes **– what’s wrong? **
Låt oss återskapa detta fel genom att jämföra en naiv och en medveten datetime:
\n>>> from django.utils import timezone\n>>> aware = timezone.now()\n>>> naive = timezone.make_naive(aware)\n>>> naive == aware\nTraceback (most recent call last):\n...\nTypeError: can't compare offset-naive and offset-aware datetimes\nOm du stöter på detta fel är det troligt att din kod jämför dessa två saker:
\nen datatid som tillhandahålls av Django - till exempel ett värde som läses från ett formulär eller ett modellfält. Eftersom du aktiverade stöd för tidszoner är den medveten.
en datatid som genereras av din kod, vilket är naivt (annars skulle du inte läsa det här).
I allmänhet är den korrekta lösningen att ändra din kod så att den använder en medveten datetime istället.
\nOm du skriver en pluggbar applikation som förväntas fungera oberoende av värdet på USE_TZ, kan du tycka att django.utils.timezone.now() är användbar. Denna funktion returnerar aktuellt datum och tid som en naiv datatid när USE_TZ = False och som en medveten datatid när USE_TZ = True. Du kan lägga till eller dra ifrån datetime.timedelta efter behov.
Jag ser massor av RuntimeWarning: DateTimeField received a naive datetime (YYYY-MM-DD HH:MM:SS) while time zone support is active **– är det dåligt? **
När stöd för tidszoner är aktiverat förväntar sig databaslagret att endast medvetna datatider tas emot från din kod. Denna varning visas när den tar emot en naiv datetime. Detta indikerar att du inte har slutfört portningen av din kod för stöd för tidszoner. Se migreringsguide för tips om den här processen.
\nUnder tiden, för bakåtkompatibilitet, anses datatiden vara i standardtidszonen, vilket i allmänhet är vad du förväntar dig.
\nnow.date() är igår! (eller imorgon)
Om du alltid har använt naiva datetider tror du förmodligen att du kan konvertera en datetime till ett datum genom att anropa dess date()-metod. Du tror också att en date är ungefär som en datetime, förutom att den är mindre exakt.
Inget av detta är sant i en miljö som är medveten om tidszoner:
\n>>> import datetime\n>>> import zoneinfo\n>>> paris_tz = zoneinfo.ZoneInfo("Europe/Paris")\n>>> new_york_tz = zoneinfo.ZoneInfo("America/New_York")\n>>> paris = datetime.datetime(2012, 3, 3, 1, 30, tzinfo=paris_tz)\n# This is the correct way to convert between time zones.\n>>> new_york = paris.astimezone(new_york_tz)\n>>> paris == new_york, paris.date() == new_york.date()\n(True, False)\n>>> paris - new_york, paris.date() - new_york.date()\n(datetime.timedelta(0), datetime.timedelta(1))\n>>> paris\ndatetime.datetime(2012, 3, 3, 1, 30, tzinfo=zoneinfo.ZoneInfo(key='Europe/Paris'))\n>>> new_york\ndatetime.datetime(2012, 3, 2, 19, 30, tzinfo=zoneinfo.ZoneInfo(key='America/New_York'))\nSom exemplet visar har samma datatid olika datum beroende på i vilken tidszon den representeras. Men det verkliga problemet är mer grundläggande.
\nEn datatid representerar en punkt i tiden. Den är absolut: den är inte beroende av någonting. Tvärtom är ett datum ett kalendrerande begrepp. Det är en tidsperiod vars gränser beror på den tidszon i vilken datumet betraktas. Som du kan se är dessa två begrepp fundamentalt olika, och att konvertera en datetime till ett datum är inte en deterministisk operation.
\nVad innebär detta i praktiken?
\nGenerellt sett bör du undvika att konvertera en datetime till date. Du kan t.ex. använda mallfiltret date för att bara visa datumdelen av en datatid. Det här filtret konverterar datatiden till aktuell tidszon innan den formateras, vilket säkerställer att resultaten visas korrekt.
Om du verkligen behöver göra konverteringen själv måste du först se till att datatiden konverteras till rätt tidszon. Vanligtvis kommer detta att vara den aktuella tidszonen:
\n>>> from django.utils import timezone\n>>> timezone.activate(zoneinfo.ZoneInfo("Asia/Singapore"))\n# For this example, we set the time zone to Singapore, but here's how\n# you would obtain the current time zone in the general case.\n>>> current_tz = timezone.get_current_timezone()\n>>> local = paris.astimezone(current_tz)\n>>> local\ndatetime.datetime(2012, 3, 3, 8, 30, tzinfo=zoneinfo.ZoneInfo(key='Asia/Singapore'))\n>>> local.date()\ndatetime.date(2012, 3, 3)\n** Jag får ett fel** ”``Är tidszondefinitioner för din databas installerade? ``”
\nOm du använder MySQL, se avsnittet Definitioner av tidszoner i MySQL Notes för instruktioner om hur du läser in tidszonsdefinitioner.
\nJag har en sträng "2012-02-21 10:28:45" och jag vet att den är i "Europa/Helsingfors" tidszonen. Hur förvandlar jag det till en medveten datatid?
Här måste du skapa den nödvändiga ZoneInfo-instansen och koppla den till den naiva datatiden:
>>> import zoneinfo\n>>> from django.utils.dateparse import parse_datetime\n>>> naive = parse_datetime("2012-02-21 10:28:45")\n>>> naive.replace(tzinfo=zoneinfo.ZoneInfo("Europe/Helsinki"))\ndatetime.datetime(2012, 2, 21, 10, 28, 45, tzinfo=zoneinfo.ZoneInfo(key='Europe/Helsinki'))\nHur får jag fram den lokala tiden i den aktuella tidszonen?
\nDen första frågan är om du verkligen behöver göra det?
\nDu bör bara använda lokal tid när du interagerar med människor, och mallskiktet tillhandahåller filter och taggar för att konvertera datatider till den tidszon du väljer.
\nDessutom vet Python hur man jämför medvetna datatider och tar hänsyn till UTC-offset när det behövs. Det är mycket enklare (och möjligen snabbare) att skriva all din modell- och vykod i UTC. Så under de flesta omständigheter kommer datatiden i UTC som returneras av django.utils.timezone.now() att vara tillräcklig.
Men om du verkligen vill ha den lokala tiden i den aktuella tidszonen kan du få den så här, för fullständighetens skull:
\n>>> from django.utils import timezone\n>>> timezone.localtime(timezone.now())\ndatetime.datetime(2012, 3, 3, 20, 10, 53, 873365, tzinfo=zoneinfo.ZoneInfo(key='Europe/Paris'))\nI detta exempel är den aktuella tidszonen "Europa/Paris".
Hur kan jag se alla tillgängliga tidszoner?
\nzoneinfo.available_timezones() ger en uppsättning av alla giltiga nycklar för IANA-tidszoner som är tillgängliga för ditt system. Se dokumentationen för användningsöverväganden.