TruncDay不Django的工作+ MySQL5.5

讓我們創建一個小的Django應用程序使用此模型：TruncDay不Django的工作+ MySQL5.5

class Thing(models.Model): 
    timestamp = models.DateTimeField(auto_now_add=True)

現在讓我們試圖讓這個日期的刪減版本：

Thing.objects.create() 

print Thing.objects.annotate(
    truncstamp=TruncDay('timestamp') 
).values('truncstamp')

如果我們只要運行在Django的查詢集，我們得到這或許可以解釋一些錯誤：

ValueError: Database returned an invalid datetime value. Are time zone definitions for your database and pytz installed?

但我已經安裝了pytz，我已經加載的時間ZON es在我的數據庫中。我的意思是，這個查詢的工作：

SELECT CONVERT_TZ(NOW(), 'SYSTEM', 'UTC');

讓我們看看會查詢它試圖運行：

print Thing.objects.annotate(
    truncstamp=TruncDay('timestamp') 
).values('truncstamp').query

這產生了查詢：

SELECT CAST(DATE_FORMAT(CONVERT_TZ(`stuff_thing`.`timestamp`, 'UTC', UTC), '%Y-%m-%d 00:00:00') AS DATETIME) AS `truncstamp` FROM `stuff_thing`

如果我嘗試運行此查詢MySQL不起作用。

ERROR 1054 (42S22): Unknown column 'UTC' in 'field list'

這裏是查詢的最小子集仍然給出了同樣的同樣的錯誤：

SELECT CONVERT_TZ(timestamp, 'UTC', UTC) from stuff_thing;

什麼是我們在這裏幹什麼？從UTC轉換到UTC？爲什麼沒有引用第二個UTC？ Django散發無效的SQL？即使你引用第二個「UTC」，你從轉換中得到的所有值都是NULL。爲什麼它甚至試圖從UTC轉換爲UTC？我們不能跳過這一步嗎？

這是一個使用默認設置的新生成的應用程序。我注意到，如果我註釋掉這個默認設置，查詢將運行：

# TIME_ZONE = 'UTC'

現在結果回來與美洲/芝加哥時區。

來源

2016-11-15 Nick Retallack

哦。精彩。我猜MySQL緩存查詢，並且緩存區分大小寫。看這瘋狂：

mysql> SELECT CAST(DATE_FORMAT(CONVERT_TZ(`stuff_thing`.`timestamp`, 'UTC', 'UTC'), '%Y-%m-%d 00:00:00') AS DATETIME) AS `truncstamp` FROM `stuff_thing` LIMIT 21; 
+------------+ 
| truncstamp | 
+------------+ 
| NULL  | 
| NULL  | 
+------------+ 
2 rows in set (0.00 sec) 

mysql> SELECT CAST(DATE_FORMAT(CONVERT_TZ(`stuff_thing`.`timestamp`, 'UTC', 'UTC'), '%Y-%m-%d 00:00:00') AS DATETIME) as `truncstamp` FROM `stuff_thing` LIMIT 21; 
+---------------------+ 
| truncstamp   | 
+---------------------+ 
| 2016-11-15 00:00:00 | 
| 2016-11-15 00:00:00 | 
+---------------------+ 
2 rows in set (0.00 sec)

我重新啓動mysql和現在兩個查詢工作。因爲我導入了時區而不重新啓動它，所以我想它已經被破壞了。

來源

2016-11-15 21:34:15

TruncDay不Django的工作+ MySQL5.5

回答

相關問題