Jag är ingen python- eller Django-guru, så kanske någon kan svara bättre än jag. Men jag ska gissa på det ändå.
Du sa att du lagrade det i ett Django DateTimeField , som enligt dokumenten du hänvisade till
, lagrar den som en Python datetime .
Tittar på dokumenten för datetime
Jag tror att nyckeln är att förstå skillnaden mellan "naiva" och "medvetna" värden.
Och sedan efterforskade jag vidare, hittade jag denna utmärkta referens
. Se till att läsa det andra avsnittet, "Naiva och medvetna datetime-objekt". Det ger lite sammanhang till hur mycket av detta som kontrolleras av Django. I grund och botten, genom att ställa in USE_TZ = true , du ber Django att använda aware datetimes istället för naiva ettor.
Så då tittade jag tillbaka på din fråga. Du sa att du gjorde följande:
dt = datetime.fromtimestamp(secs)
dt = dt.replace(tzinfo=utc)
Tittar på fromtimestamp funktionsdokumentation, jag hittade den här biten text:
Så jag tror att du kan göra så här:
dt = datetime.fromtimestamp(secs, tz=utc)
Återigen, precis under den funktionen, visar dokumenten utcfromtimestamp funktion, så det kanske borde vara:
dt = datetime.utcfromtimestamp(secs)
Jag kan inte tillräckligt mycket om python för att veta om dessa är likvärdiga eller inte, men du kan försöka se om någon av dem gör någon skillnad.
Förhoppningsvis kommer en av dessa att göra skillnad. Om inte, vänligen meddela mig. Jag är väl bekant med datum/tid i JavaScript och i .Net, men jag är alltid intresserad av hur dessa nyanser utspelar sig annorlunda på andra plattformar, som Python.
Uppdatera
Angående MySQL-delen av frågan, ta en titt på denna fiol .
CREATE TABLE foo (`date` DATETIME);
INSERT INTO foo (`date`) VALUES (FROM_UNIXTIME(1371131402));
SET TIME_ZONE="+00:00";
select `date`, UNIX_TIMESTAMP(`date`) from foo;
SET TIME_ZONE="+01:00";
select `date`, UNIX_TIMESTAMP(`date`) from foo;
Resultat:
DATE UNIX_TIMESTAMP(`DATE`)
June, 13 2013 13:50:02+0000 1371131402
June, 13 2013 13:50:02+0000 1371127802
Det verkar som om beteendet hos UNIX_TIMESTAMP funktionen påverkas verkligen av MySQL TIME_ZONE miljö. Det är inte så förvånande, eftersom det finns i dokumentationen. Vad som är förvånande är att strängutgången för datetime har samma UTC-värde oavsett inställning.
Här är vad jag tror händer. I dokumenten för UNIX_TIMESTAMP funktion, står det:
Observera att det inte står att det kan vara en DATETIME - det står att det kan vara en DATETIME sträng . Så jag tror att det faktiska värdet implicit konverteras till en sträng innan det skickas till funktionen.
Så titta nu på denna uppdaterade fiol som konverterar explicit.
SET TIME_ZONE="+00:00";
select `date`, convert(`date`, char), UNIX_TIMESTAMP(convert(`date`, char)) from foo;
SET TIME_ZONE="+01:00";
select `date`, convert(`date`, char), UNIX_TIMESTAMP(convert(`date`, char)) from foo;
Resultat:
DATE CONVERT(`DATE`, CHAR) UNIX_TIMESTAMP(CONVERT(`DATE`, CHAR))
June, 13 2013 13:50:02+0000 2013-06-13 13:50:02 1371131402
June, 13 2013 13:50:02+0000 2013-06-13 13:50:02 1371127802
Du kan se att när den konverterar till teckendata tar den bort offseten. Så naturligtvis är det vettigt nu när UNIX_TIMESTAMP tar detta värde som indata, det antar den lokala tidszonsinställningen och får därmed en annan UTC-tidsstämpel.
Inte säker på om detta kommer att hjälpa dig eller inte. Du måste gräva mer i exakt hur Django anropar MySQL för både läsning och skrivning. Använder den verkligen UNIX_TIMESTAMP fungera? Eller var det bara det du gjorde när du testade?