Proč nastavení časového pásma Django ovlivňuje čas epochy?

Nejsem žádný krajta ani guru Django, takže možná někdo odpoví lépe než já. Ale stejně to budu hádat.

Řekl jsi, že to ukládáš do DateTimeField Django , což podle dokumentů, na které jste odkazovali , uloží jej jako Python datetime .

Podívejte se na dokumenty pro datetime , Myslím, že klíčem je pochopení rozdílu mezi „naivními“ a „aware“ hodnotami.

A při dalším zkoumání jsem narazil na tuto vynikající referenci . Ujistěte se, že jste si přečetli druhou část, "Naivní a vědomé objekty typu datetime". To dává trochu kontextu k tomu, jak moc z toho Django ovládá. V podstatě nastavením USE_TZ = true , žádáte Djanga, aby použil aware datetimes namísto naivní jedničky.

Tak jsem se podíval zpět na vaši otázku. Řekl jste, že děláte následující:

dt = datetime.fromtimestamp(secs)
dt = dt.replace(tzinfo=utc)

Při pohledu na fromtimestamp dokumentace funkce, našel jsem tento kousek textu:

Takže si myslím, že byste mohli udělat toto:

dt = datetime.fromtimestamp(secs, tz=utc)

Pak znovu, přímo pod touto funkcí, dokumenty zobrazují utcfromtimestamp funkce, takže by to možná mělo být:

dt = datetime.utcfromtimestamp(secs)

Nevím o pythonu dost na to, abych věděl, zda jsou ekvivalentní nebo ne, ale můžete zkusit, zda je v něčem rozdíl.

Doufejme, že jeden z nich změní. Pokud ne, dejte mi prosím vědět. Důvěrně znám datum/čas v JavaScriptu a v .Netu, ale vždy mě zajímá, jak se tyto nuance projevují odlišně na jiných platformách, jako je Python.

Aktualizovat

Pokud jde o část otázky týkající se MySQL, podívejte se na tyto housle .

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;

Výsledky:

DATE                           UNIX_TIMESTAMP(`DATE`)
June, 13 2013 13:50:02+0000    1371131402
June, 13 2013 13:50:02+0000    1371127802

Zdá se, že chování UNIX_TIMESTAMP funkce je skutečně ovlivněna MySQL TIME_ZONE nastavení. To není tak překvapivé, protože je to v dokumentaci. Překvapivé je, že výstup řetězce datetime má stejnou hodnotu UTC bez ohledu na nastavení.

Zde je to, co si myslím, že se děje. V dokumentech pro UNIX_TIMESTAMP funkce, říká:

Všimněte si, že neříká, že to může být DATETIME - říká, že to může být DATETIME řetězec . Takže si myslím, že skutečná hodnota je před předáním do funkce implicitně převedena na řetězec.

Nyní se tedy podívejte na tyto aktualizované housle který převádí explicitně.

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;

Výsledky:

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

Můžete vidět, že když se převede na znaková data, odstraní offset. Takže to samozřejmě dává smysl teď, když UNIX_TIMESTAMP bere tuto hodnotu jako vstup, předpokládá nastavení místního časového pásma a získává tak jiné časové razítko UTC.

Nejste si jisti, zda vám to pomůže nebo ne. Musíte se podrobněji zabývat tím, jak přesně Django volá MySQL pro čtení i zápis. Opravdu používá UNIX_TIMESTAMP funkce? Nebo to bylo přesně to, co jste dělali při testování?