在编码中牵扯到时间问题的时候，总是容易被时区问题搞混，一直以来，都是反复试验应付过去，今天终于搞清楚了个中缘由，一个心结也得以化解。
python 的时区问题
datetime.today() / datetime.now()
这两个函数获得的是当前的系统时间，但得到的datetime对象中的tzinfo是空的，即使系统中设置了时区。
datetime.utcnow()
这个函数获得当前的utc时间，应该是根据当前系统时间和时区来计算的。
例如系统时间为14：00，时区为 asia/shanghai (北京时间)，utcnow返回时间为 6：00。同样，得到的对象中的tzinfo 为空。
环境变量 tz 对以上函数的影响：
当系统中设置了环境变量 tz 的时候，或者在python中设置了 os.environ[‘tz’] 的时候，上面的函数获取的时间便是tz对应时区的时间。其实这里可以认为 tz 影响的不是这些函数，而是影响的系统时间，这可以从date命令的返回结果看出。datetime.now() 与 date命令返回的结果总是一致的。
django的时区问题
明白了上面几个python中的函数，django的时区问题看起来就简单了。
在django的setting中，有一个设置是 time_zone， 来设置程序中使用的时区。
从django的文档中得知，time_zone的作用就是改变 os.environ[‘tz’] ，但改变os.environ[‘tz’] 并不会改变系统环境变量 tz ， 因此，如果 time_zone 的设置于系统时区设置不一致，则在程序中 datetime.now() 获得的时间就与 date 命令的时间不一致了。
因此，time_zone 应该设置为程序希望使用的时区。对于一个本地的程序，time_zone 设置为与系统时区一样即可；而对于一个国际化的应用，time_zone 最好设置为utc，在显示的时候再根据当前用户所在的时区做调整。
手册
classmethod datetime.now([tz])
return the current local date and time. if optional argument tz is none or not specified, this is like today(), but, if possible, supplies more precision than can be gotten from going through a time.time() timestamp (for example, this may be possible on platforms supplying the c gettimeofday() function).
else tz must be an instance of a class tzinfo subclass, and the current date and time are converted to tz‘s time zone. in this case the result is equivalent to tz.fromutc(datetime.utcnow().replace(tzinfo=tz)). see also today(), utcnow().
classmethod datetime.utcnow()
return the current utc date and time, with tzinfo none. this is like now(), but returns the current utc date and time, as a naivedatetime object. see also now().
时区转换代码
import pytz
….
#dt the datetime var
dt.replace(tzinfo=pytz.utc).astimezone(pytz.timezone(‘asia/shanghai’))