Ik ben geen python of Django-goeroe, dus misschien kan iemand beter antwoorden dan ik. Maar ik gok er toch maar op.
Je zei dat je het opsloeg in een Django DateTimeField , die volgens de documenten waarnaar u verwijst
, slaat het op als een Python datetime .
Kijkend naar de documenten voor datetime
, Ik denk dat de sleutel is om het verschil tussen "naïeve" en "bewuste" waarden te begrijpen.
En toen ik verder onderzoek deed, kwam ik deze uitstekende referentie
tegen . Zorg ervoor dat u het tweede gedeelte, "Naïeve en bewuste datetime-objecten" leest. Dat geeft een beetje context aan hoeveel hiervan wordt gecontroleerd door Django. Kortom, door USE_TZ = true in te stellen , je vraagt Django om aware . te gebruiken datetimes in plaats van naïef die.
Dus toen keek ik terug naar je vraag. Je zei dat je het volgende deed:
dt = datetime.fromtimestamp(secs)
dt = dt.replace(tzinfo=utc)
Kijkend naar de fromtimestamp functiedocumentatie, ik vond dit stukje tekst:
Dus ik denk dat je dit zou kunnen doen:
dt = datetime.fromtimestamp(secs, tz=utc)
Aan de andere kant, direct onder die functie, tonen de documenten utcfromtimestamp functie, dus misschien zou het moeten zijn:
dt = datetime.utcfromtimestamp(secs)
Ik weet niet genoeg over python om te weten of deze gelijkwaardig zijn of niet, maar je zou kunnen proberen of een van beide een verschil maakt.
Hopelijk maakt een van deze het verschil. Zo niet, laat het me weten. Ik ben goed bekend met datum/tijd in JavaScript en in .Net, maar ik ben altijd geïnteresseerd in hoe deze nuances anders uitpakken op andere platforms, zoals Python.
Bijwerken
Wat betreft het MySQL-gedeelte van de vraag, bekijk deze viool .
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;
Resultaten:
DATE UNIX_TIMESTAMP(`DATE`)
June, 13 2013 13:50:02+0000 1371131402
June, 13 2013 13:50:02+0000 1371127802
Het lijkt erop dat het gedrag van UNIX_TIMESTAMP functie wordt inderdaad beïnvloed door de MySQL TIME_ZONE instelling. Dat is niet zo verwonderlijk, aangezien het in de documentatie staat. Wat verrassend is, is dat de string-output van de datetime heeft dezelfde UTC-waarde, ongeacht de instelling.
Dit is wat ik denk dat er gebeurt. In de documenten voor de UNIX_TIMESTAMP functie, staat er:
Merk op dat er niet staat dat het een DATETIME . kan zijn - er staat dat het een DATETIME kan zijn tekenreeks . Dus ik denk dat de werkelijke waarde impliciet wordt geconverteerd naar een tekenreeks voordat deze wordt doorgegeven aan de functie.
Dus kijk nu naar deze bijgewerkte viool die expliciet converteert.
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;
Resultaten:
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
U kunt zien dat wanneer het wordt geconverteerd naar tekengegevens, het de offset wegneemt. Het is dus logisch dat wanneer UNIX_TIMESTAMP neemt deze waarde als invoer, gaat uit van de lokale tijdzone-instelling en krijgt dus een ander UTC-tijdstempel.
Niet zeker of dit je zal helpen of niet. Je moet meer weten over hoe Django MySQL aanroept voor zowel lezen als schrijven. Gebruikt het daadwerkelijk de UNIX_TIMESTAMP functie? Of was dat precies wat je deed tijdens het testen?