时区和夏令时的最佳实践当需要一个确定时刻，保留一个持续化的并和夏令时无关的统一时间。GMT和UTC都适用于这种情况，但U

当需要一个确定时刻，保留一个持续化的并和夏令时无关的统一时间。GMT和UTC都适用于这种情况，但UTC会好一些。GMT是一个时区，而UTC是一个标准。
如果选择存储本地时间的话，请把本地时间和UTC时间的时间差也记录下来。注意，时间差在一年中的某些月份可能会变。这样后面使用的时候才能被计算成确切时间。
有时，你也需要考虑把UTC和本地时间都存储下来。常常，我们会考虑把他们分布存储到两个字段里面，但有些平台上，他们可以被存储在一个平台里面，如MSSQL 的datetimeoffset字段(docs.microsoft.com/en-us/sql/t…); 而这个不是sql标准字段。
当需要把日期存储为数字类型，使用Unix Time (en.wikipedia.org/wiki/Unix_t…) 如需要精确的时间，请考虑替换为毫秒级别。这个数字基于UTC，没有做任何timezone调整。Java: new Date().getTime(); JS: new Date().getTime() 或 +new Date都可以。
如果以后需要修改这个时间戳，请顺带记录上原来时区的ID，用以判断时间差和原来存储时间比较是否变化了。
如果是为计划未来的定期任务，存储本地时间会比存储UTC更好，因为通常会有时间差的改动。比如使用UTC设置你每天的闹钟，有时候，你将早起来一个小时，夏令时过度到时候，你就会上班迟到一小时了:) stackoverflow.com/questions/1…
当你计划一整天的时间，不要转成UTC或者其他任何时区来记录。
- 数据库里面这种字段尽量不要包含时刻信息。保留到天即可。
- 如果数据库或存储平台不允许这样做，那么尽量在读取时忽略时刻的意义。如果确实不确定，那么我们尽量采用正午12：00，而不要用午夜0：00来显示这个时刻。
注意时区差并不是永远都是整数。比如Indian Standard Time is UTC+05:30, and Nepal uses UTC+05:45
相比UTC或者GMT，很多商业规则使用Civil time会更多。安排计划时需要把UTC时间戳转换到本地时区。
时区和偏移值不是一个常量，可能会变。
考虑时间类型（确定时间，海外时间，相对时间，历史时间，计划循环时间），你需要采用不同的存储方式保证时间不会缺失。
让你的操作系统，数据库和应用程序保持一致。
服务器上，设置硬件时钟和操作系统时钟为UTC时间，非本地时间。
服务器端代码，包含网站，永远不要指望服务器本地时间能有意义。
根据你的应用，把时间的设置分成若干种类，对于不同的种类设计适当的存储方案。不要做全局设置。
服务器使用网络时间协议
考虑在FAT32/16的设备上使用本地时间。理由比较奇葩。比如在DOS时代，个人电脑都没有网络功能，时间都是使用Bios时间，存储在3.5寸软盘上。那时人们完全不会关心软盘上面存储的时间，而会使用铅笔在盘面上写下处理时间。因此这些时间不会准确。回到现在，很多移动设备，比如相机等还在使用FAT类型格式；当你在另一个时区时，这些时间不会被改变，如果存储时间戳，就会导致存储时间的混乱。所以存储本地时间会更好。
当设置周期时间时，比如跟美剧，每周一集更新那种，记住时间会因为夏令时，在不同时区会有不同。
使用>=判断下限，用<判断上限。