哎，没成过一个的感觉。。失落感不要太强！

为什么后端不知道怎么校验。。

期待『支付宝』小程序(认真脸

#同时创建订单行项目并能增行# 没明白；
你是说需要保持 django 单个请求的事务性的问题么？
这个直接搜搜

或者说是需要在创建订单明细时候，需要订单 Id 的问题？可以参照下面的
伪代码：

order = Order(name=name,xxxx)

order.save(commit=False)

detail = Detail(order=order)

detail.save()

order.save()

===

主要是个 commit=False 的用法

我忍不住出来说两句，吐槽小米其他的我不说话，大多说确实挺客观的；

但是张口就是说全是广告的你们到底是自己用过还是听别人说的？我自己已经记不得上次被广告是什么时候了，也许有一年了？。

对于 miui 自家推送的营销消息，我承认这个确实是有过，但是你只要动动手指关掉，之后就没有这类通知了。

任何一个机器，无论 android 还是 iphone ，每次 app 要通知权限，你们都给的话，谁手机上不满是『广告』！权限控制，消息通知自己稍微关注处理下，就没有任何问题，你们这些为黑而黑的真心没意思。

多语言第一反应居然是领导让你用 php 写一套，用 java 写一套，用 nodejs 写一套等等。。。😂

@wwhc 感觉这个这个才是正确的姿势。难道是因为年纪大了的原因么，哈哈

@hao1032 不是 bug ；
你传入的是 now.day ，这个是个 int~~

如果你服务器时间就是 Asia/Shanghai 的话，直接使用 datetime.now()就好了；

USE_TIME ==> USE_TZ

append ：

源码部分， django/db/backends/mysql/operations.py ， 1.8 和 1.9 处理逻辑一致；
如果是 linux 的话，可以用 ack 搜下 CONVERT_TZ 就出来了。

@hao1032

抱歉关于 TIME_ZONE 这个理解错了。


整体重新说一下，虽然 1.8 版本的说明和 1.9 ， 1.10 不一样，但是数据库存储的时间都是标准的 UTC 时间。(之前说的是存储的是基于 TIME_ZONE 的时间，这个是错误的)

我本地跑了下 1.8 ， 1.9 ，分别设置 TIME_ZONE 为「 UTC 」和「 Asia/Shanghai 」，后台登陆，看数据库里面的时间，也确实是 UTC 时间，现在我电脑时间是， 2016 年 09 月 06 日 12:22:37 ，但是数据库中存储的都是凌晨 4 点的，正好-8 ；

至于你的为什么会出现 CONVERT_TZ ，是因为你开启了 USE_TIME 。
你用的 now.day 是 UTC 时间，而 Django 认为这个时间是 TIME_ZONE 时间；
所以生成 sql 时候，先把数据库中数据时间，转成 TIME_ZONE 时间，然后和你的 day 进行比较；

所以你应该使用


from django.conf import settings
from django.utils import timezone
import pytz

now = timezone.now()
tzinfo = pytz.timezone(settings.TIME_ZONE)
now = now.replace(tzinfo=tzinfo)


然后传入此时的 now.day ，获取到的应该就是正确的数据了

http://ww2.sinaimg.cn/large/5dad00d9jw1f7j4fzr8nkj20gg04ljs8.jpg

django.db.backends.mysql _convert_field_to_tz

1.是对的
2. 由于配置中 USE_TZ 设置为 True ，那么保存在 add_time 里的时间也是 utc 时间（ add time 在 model 中设置为 auto now add 为 True ）
这个是不对的，参照这里： https://docs.djangoproject.com/en/1.10/ref/settings/#time-zone

This allows interacting with third-party databases that store datetimes in local time rather than UTC. To avoid issues around DST changes, you shouldn ’ t set this option for databases managed by Django.

When USE_TZ is True and the database doesn ’ t support time zones (e.g. SQLite, MySQL, Oracle), Django reads and writes datetimes in local time according to this option if it is set and in UTC if it isn ’ t.


也就是说你数据库里面的存在不是 UTC ，而是基于 TIME_ZONE 的地区时间；所以后面才有 CONVERT_TZ 的时区转换；

@lvwzhen 这我就尴尬了。。。😓
@kevinzhow

@chimingphang

我看了你的数据，是每 5 分钟一条的；

没搞过这个，不过可以给点思路，就是根据时间单独取数据绘制(3 分钟为间隔的， 5 分钟为间隔的)；


参照下 okcoin 的设计， https://www.okcoin.cn/market.do ，每个时间间隔，都是单独取数据，重新绘图；
比如 15 分钟图，那么就从后台获取 15 分钟间隔的数据(1000 条)，然后 窗口 用 100 个宽度，这样子向左拖动，可以拖动 10 屏，基本上够用了；


如果按照你现在的搞，
像你说的那个样子， 3 ， 5 ， 15 ，那么后台应该传过来最小公约数 1 分钟的，然后你自己计算 group ；重新绘制；不过这个样子， 15 分钟时候，显然需要数据量太大，不划算；

你先把问题说清楚，最好能搞个在线可运行的 demo ，大家就都很乐意免费给你搞了；

你这样子问题不太清楚，谁也不敢接，接了搞不定就尴尬了。