推荐学习书目
› Learn Python the Hard Way
Python Sites
› PyPI - Python Package Index
› http://diveintopython.org/toc/index.html
› Pocoo
值得关注的项目
› PyPy
› Celery
› Jinja2
› Read the Docs
› gevent
› pyenv
› virtualenv
› Stackless Python
› Beautiful Soup
› 结巴中文分词
› Green Unicorn
› Sentry
› Shovel
› Pyflakes
› pytest
Python 编程
› pep8 Checker
Styles
› PEP 8
› Google Python Style Guide
› Code Style from The Hitchhiker's Guide
This topic created in 3757 days ago, the information mentioned may be changed or developed.
Supplement 1 · Jul 21, 2016
评论下有人建议使用 unix 时间戳，但是 unix 时间日期是 1970~2038 ，不再这个范围的不是会出现问题？
 |
julyclydeJul 21, 2016
1
保存的时候应该用 UTC ，但似乎很少有遵守的
展现的时候当然要本地化了 |
 |
haozhangJul 21, 2016 via iPhone
2
保存全部使用 utc 我觉得的是最佳方案，取值转换成 local time 即可
|
 |
cevincheungJul 21, 2016
3
为什么就不能存时间戳。
|
 |
pubbyJul 21, 2016 via Android
5
一律使用同一个时区，所有机器 NTP 对时，时区设置相同即可
|
 |
skydiverJul 21, 2016
6
一律使用 unix 时间戳
|
 |
imnpcJul 21, 2016
8
只建议用 unix 时间戳...
|
 |
10
@cevincheung 如果涉及到个人生日呢？
|
|
12
|
|
cevincheungJul 21, 2016
13
|
|
14
@cevincheung 64 位 ubuntu 14.04 输出这个： Tue Jan 1 01:11:01 CST 2999
|
|
cevincheungJul 21, 2016
15
@myyou 对啊。
|
 |
loadingJul 21, 2016 via Android
17
unix 时间是从 1970 年 01 月 01 日 0:00:00 起算，用的是 utc 时区，所以也可以理解是另一种 utc 时间。
2038 年是 32 位长度带来的精度问题，这个问题不同于千年虫问题。千年虫是判断 2000 年是闰年，少了一个判断，是代码错误。 64 位的 unix 时间够用了，而且现在大家其实都在用了。 |
 |
21
搞清楚你的应用几国人在用，生命周期是多久，就清楚了
|
1 |
caixiexinJul 21, 2016 via Android
23
小于 1970 年的 Unix 时间戳，不是负数吗
|
 |
kookxiangJul 21, 2016
24
unix 时间戳是到 2038 年？那只是因为你用 32 位的 int 来存而已吧
|
 |
x8Jul 21, 2016
25
64 位的机器会有这个问题吗？
|
 |
onlyiceJul 21, 2016
28
|
 |
expkzbJul 21, 2016
29
时间戳的问题在于不能表示时区，遇到航班信息就傻眼了
|
 |
tausi0661Jul 22, 2016
32
是不是 utc/unix 无所谓, 只要存储的所有时间是统一的时区就好, 并保证各 server 的时区及时间一致.
|
 |
lifanxiJul 22, 2016
33
@loading
重复一下 26 楼的话：千年虫不是闰年问题，是年份只用了两位整数来存的问题。参考老版的 13 位身份证号码来理解。 2000 年是闰年，而 1900 年不是，如果把 2000 年误作 1900 年，确实会造成 2 月少一天的问题。但这不是通常“千年虫”讨论的范畴，也不是像你说的那样，因为“千年虫是判断 2000 年是闰年，少了一个判断”， 2000 年是闰年没有问题，你说的“少了一个判断”（能否整除 400 ）只会造成把 1900 年也判成闰年。 |
 |
mengzhuoJul 22, 2016 via iPhone
34
是
等你们公司开始做国际化的时候 后面的程序员会感谢你的 |
 |
xuboyingJul 22, 2016 via Android
35
@expkzb 航班时间这种涉及跨时区的不用时间戳才傻了。记录了时间戳用户才能得到不同时区的时间正确表示，特别是还有地方有夏时制冬时制，每次显示都要换算正确
|
|
lifanxiJul 22, 2016
36
时间其实是个很复杂的东西，但是可以把它理解成是个自然流逝的东西，然后人为给每一秒（毫秒也行，单位不重要，取决于你需要精度）进行计数。
这个计数值在计算机领域通常可以用 Unix 时间戳来表示，在不考虑实现（变量位数）的前提下，这个计数值可以表示任意时间范围。所谓只能表示 1970-2038 是因为假设了只用有符号 32 位整型数的非负数部分对秒计数的原因。 所以，用一个足够长的有符号整数来表示任意时间是没有问题的。但这个数值本身并不具有“时区”的含义，时区只在把它转换为人类可读的表示方式时才要考虑的问题。 这个转换工作应该 100%交给操作系统去实现，而不应该自己土法按一年 365/366 年、每天 24 小时、每小时 60 分钟、每分钟 60 秒再加上时间偏移去计算，甚至前一天、后一天这种计算也应该用系统库去完成，而不要自己去做。 因为时间日期计算里有太多坑了，基本上 99.9%的程序员自己实现的版本不会比系统已有的版本要好。最简单的有闰年、复杂一点的时区和夏时制、再复杂一点有闰秒、更复杂一点是一些历史特殊情况（比如时区变更）。 |
 |
yaodongJul 22, 2016
37
http://yellerapp.com/posts/2015-01-12-the-worst-server-setup-you-can-make.html
> TL;DR Use UTC as the only timezone for your servers. |
 |
BlueMeowJul 22, 2016
38
@lifanxi 对。有时候由于临时增加的闰秒、地区时区调整、夏令时等问题，时间存在处理各种陷阱。比如 http://stackoverflow.com/questions/6841333/why-is-subtracting-these-two-times-in-1927-giving-a-strange-result 这个问题就是因为 1927 年上海时区调整引起的，这种细节自己处理的话总会有疏漏。
|
 |
bingwenshiJul 22, 2016
39
做个编程习惯良好的工程师，把时间都存储成 UTC 时间， 只是在展示的时候，根据用户时区再做转换就行了
|
|
julyclydeJul 22, 2016
40
使用 UTC 可以保证时序
不要忘了所谓弟弟比哥哥先出生的夏令时事故 |
|
julyclydeJul 22, 2016
43
另外 China standard time 据说不支持闰秒，在闰秒时会两次出现 59 秒，有可能发生逆序事故； UTC 是支持的
|
|
xuboyingJul 22, 2016 via Android
46
@expkzb 是啊，下面也是表示要用 epoch 。时间戳表示了一个确定的时刻， human 时间只是加上时区 /dst 的时间戳不同表现显示而已
|
 |
silver107Jul 22, 2016
47
存时间戳，是不是没有时区问题
|
 |
rubyvectorJul 22, 2016
48
最近也遇到此问题.如果用户是跨时区的,可得注意了.不然大乱
|
 |
ComdexJul 22, 2016
49
@rubyvector
@julyclyde @bingwenshi @lizon @skydiver 请教一下各位，在数据库中保存时间是使用 datetime 或字符串还是使用 int64 类型保存时间截好？现在比较普遍的做法是怎样的？ |
 |
quixJul 22, 2016
50
@myyou 生日的话... 并不是时间 只是个几月几日的信息, 连年份都没有
如果说的是出生日期( dob) 的话则是一个不含时区的日期 因此也不应该是作为时间戳保存而应该作为字符串保存 ( 如果需要查询时进行比较可以存成统一时区的日期, 最好是 utc ) |
 |
MiranaJul 22, 2016
51
存时间戳也有时间问题啊 主要是是时区的问题
|
 |
jyboxJul 22, 2016
52
首先内部表示和物理层面肯定是存 UTC ，几乎所有数据库都是这样的（他们接受任何时区的时间，但会存成 UTC ）。但如果你存 UTC 的话，一定要把时区也一起存起来（可能要放到单独的字段，要看数据库支持不支持）。
因为时区是一个有关时间的重要元信息（和时区相关联的不仅仅是偏移量，还包括夏令时和冬令时之类的东西），当然不应该丢掉它。否则例如一个人在中国发了一个帖子，又去美国发了一个帖子，那么如果服务器不存时区，只依赖客户端时区的话，就可能会发现两个帖子是同一时间，甚至后一个帖子的时间比前一个更早。 至于客户端和服务器端之间的 API ，我认为双方都要有接受任何时区的时间的能力，现在绝大部分的语言都提供了这样的能力。发送的时候，客户端按照本地时区发送（以便把时区这个信息传递给服务器）；服务器在发送时，则以数据库中记录的，客户端的时区来发送。 |
|
x8Jul 22, 2016
53
|
 |
cxbigJul 22, 2016
54
我司服务器时间和存数据库的各种时间一律用 UTC ，前端根据实际业务时区做转换输出输入。
|
 |
mgcnrx11Jul 22, 2016
55
@julyclyde 请教一下，看了一下 wiki 上 UTC 的介绍， UTC 是会在适当的时候增加闰秒来保持与 GMT 不差超过 1 秒的。那么，对于要做日期转换的工具库（类）来说，岂不是需要针对未来未知的某个闰秒做更新，才能正确转换时间？否则闰秒会造成转换的时候多了一秒这种情况吧？
|
 |
dorentusJul 22, 2016 via iPhone
56
你的操作系统底层都是用 unix epoch 或者类似 unix epoch 的方式表达时间的。
|
 |
owt5008137Jul 22, 2016 via Android
57
@myyou 现在 unix 时间戳基本上都用 int64 保存了，除非你强制往 int32 转。所以反正你活着的时候肯定够用了
|
 |
janxinJul 22, 2016
58
UNIX 时间戳用 int64 ，够用了啊
|
|
julyclydeJul 22, 2016
59
@mgcnrx11 首先你要知道 UTC 是根本，闰秒是在 UTC 里做的；到各个行政时区，是 59 秒之后 60 秒，还是 59 秒之后又一个 59 秒，或者做夏令时处理，那是各国政府自己的事了。保存、传输都用 UTC ，直到最后展现的时候才用行政时区，可以做到损失的最小化
|
|
julyclydeJul 22, 2016
60
https://access.redhat.com/articles/1187353
http://www.cnbeta.com/articles/437413.htm https://mm.icann.org/pipermail/tz-announce/2015-August/000033.html Changes affecting future time stamps North Korea switches to +0830 on 2015-08-15. (Thanks to Steffen Thorsen.) The abbreviation remains "KST". |
 |
banxi1988Jul 23, 2016
61
首先,支持 UTC, 但是主要的是要统一啊,
印象中,以前 LeanCloud 是 +8 时间,后来改成统一 UTC 时间了. |
Select Language