都 2022 年了，居然许多国内的厂商还没有时区的概念

[toaruScar]

系统时区不是 UTC+8 （中国时区，CST ）的话，许多登录时申请短信验证码请求都会失败，不知是蠢还是坏。

目前，系统使用非中国时区的时候，遇到过的糟糕体验有：

• 中信银行，提示参数错误；（我第一次遇到，挂了国内 IP 都不行，让我琢磨了好半天）
• 中国移动的语音信箱，正常 GUI 交互触发的验证码请求被当成重放攻击，导致被拦截

这些的解决方法是把系统的时区（是时区，不是时间）调到 UTC+8 的时区即可，反而国内的 IP 不是必须的。

国内互联网加拉帕戈斯化更进一步了。

[moen]

看看一些人对数据库表示时间用什么类型的回答就知道了

[singerll]

不是没有这个概念，是没有这个业务，就算有也是体量太小。。。

[ysjiang4869]

有些业务惨和上时区后复杂度会提升很多，不愿意为了几百个人浪费呗（我司就是这样）

[PMR]

人和业务 其一能跑就行

没 i18n 基本不用 timestamp 存时间

[pengtdyd]

不同时区混杂在一起很难处理

[agagega]

没有 i18n ，没有 l10n ，没有时区概念，对多语言支持甚至不如一些英语国家产品（中文支持也仅仅是 just works 而已）

不过我还是很好奇，为什么时区不一样会导致验证码出错，难道是靠客户端的时间戳来做检查的？

[toaruScar]

@agagega 不是验证码出错，是连验证码都要不来。


@singerll
@ysjiang4869
@pengtdyd
可能我想得太简单了，不过我感觉就一个验证码的功能，在客户端把时间转换成 CST 的时间再发给后端就行了。另外就算不打算支持，也没必要把错误信息搞得和谜语一样，简单地提示用户时区问题会导致登录错误也不算太复杂把。

[JensenQian]

反正很多都是只支持+86 登陆的
有+86 手机号还不生活在国内的也没几个人啊

[toaruScar]

@JensenQian #8 我朋友最近急事出国，语音信箱突然不能登录把他急坏了

[singerll]

@toaruScar 有没有一种可能，人家压根就没有多时区的测试环境

[Rocketer]

海外党表示这种问题见太多了，都麻了。

比如某著名手游，在里面参加国庆活动，仅限 10.1 当天参加。那么，到底是北京时间的 10.1 ，还是我本地时间的 10.1 呢？最后实测发现我的手机和北京时间都得是 10.1 才行，二者有一个不对就不能参加。有些活动还只能点一次，在“错误的”时间不小心参加了，就浪费资格了。

[kylix]

我也说一个，银联云闪付，够大的公司了吧。
ios 版如果手机设置了 12 小时制，其他某些应用如淘宝调转支付无法唤起支付页面。/滑稽


月初还这样，不知道最近改了没有。。。

[likunyan]

做灰色的才会考虑这些吧

[likunyan]

微信这些应该没问题，机构的人性化肯定没私人的好。

[az467]

不是不懂，起码银行肯定懂，不然外币相关业务没法做，
纯粹就是不想做，投入大，收益小，还容易引入海量 BUG 。

[bclerdx]

@kylix 为什么不使用 24 小时制。

[bclerdx]

@Rocketer 如果不是国际业务，理论上，默认行为是北京时间啊。

[bclerdx]

@az467 有 BUG ，解决 BUG 啊。

[0o0O0o0O0o]

腾讯云控制台的日志也是，选时间段可麻烦

[ZeroClover]

不只是「国内」厂商

刚才用 HSBC US 转账，美国现在是 10 月 30 日，国内 10 月 31 日，然后 HSBC 系统预填了 Transfer Date 10/30/2022 ，然后确认按钮就是灰色的，只能手动选 10/31/2022 才能点击确认。但是把系统时区改到美国就可以选 10/30/2022

这还是一个全球性银行的系统

[dayeye2006199]

数据库很多存储的都是不带时区的字符串，一把梭

[darkengine]

大伙儿有没有听说过 daylight saving time

[zx900930]

这算啥，还有逗号作为小数点，分号作为表格分隔符的 bug. 牵扯到 locale 的问题，需要花很多精力维护，没有国际化的业务，不考虑这些“特殊”用户才是上策。

[mringg]

苹果商城都处理的莫名其妙的，譬如取货日期是购买日期的前一天

[moreant]

@kylix 我也遇到这个 bug 了。好奇诺大的云闪付团队没有一个是使用 ios 系统设置 12 小时用过自家 APP 的吗，这种可以简单复现的 bug 这么久都还在

[julyclyde]

平常有人升级 tzdata 么
有人升级 ca-certificate 么

[wu67]

这有啥的. 我跟你讲, 国内最大的通信商之一, 内部系统的数据, 都没记录时区的. 然后基站出事自动派工单(让人去处理)时, 那个酸爽...东 8 区的某个时间点出事, 它系统用中时区的记录, 多刺激.....

[zoharSoul]

懒得为极少数用户付出很大的成本

[janxin]

没有用户需求就没这个动力

[cyll]

@kylix 笑死 我说前一段时间用怎么没法付款。。然后就卸载了。
原来是因为我用的 12 小时制（

[nothingistrue]

能发出这种感慨，说明你干开发的时间少。Java 8 加入不用考虑时区的 java.time.LocalDateTime 时，无时区的时间，在当时可以质的提升。不同于文本显示国际化，时间的国际化，绝大多数情况下都是成本极大高于收益的东西。

[wuych]

国内只有一个时区，不想北美那边有好几个市区，所以大陆没有国际化业务的厂商基本上代码里都是写死的 GMT+8

[sadfQED2]

我们国内业务和国际业务都分成两个项目来做，代码库都是两套。为啥要分两套呢，因为国内代码引入时区和翻译难度太大，还不如重写

[unco020511]

@sadfQED2 #33 我们是一套,但平时都是分开仓库,每个季度合并一次,因为国内海外有很多共性功能和能力.分有分的好,合有合的好

[zhchyu999]

你想太多了，你就不是人家的目标客户

[Mohanson]

涉及时间一律 timestamp 无烦恼

[YUCOAT]

玩过一款国产手游，在海外发行的。同一个服务器里，有世界各地的玩家。游戏里面用的是 UTC 时间，游戏界面的左上角有一个时钟显示当前的 UTC 时间，我感觉挺好的。

[Rocketer]

@Mohanson 我在美加做过的公司都是用数据库的日期类型，各种语言也都有兼容的日期类。

这里的理念是时区不要自己转，因为还有夏令时的问题，让系统处理最方便还不会错。但中国公司喜欢用时间戳自己算，也不知道为什么。

[nulIptr]

组里最近做对话机器人这个边缘情况可多了。。。
机器人自己的时区->创建的时候可选
机器人服务器所在时区->看供应商在哪
终端用户时区->看跟机器人聊天的人在哪，这有个问题是如果问机器人现在的时间应该回复用户时间还是机器人时间
搭建机器人的平台上面显示的日志时间->中国的运营人员搭建一个面向美国用户的机器人，他看到的日志应该是哪个时区？如果运营人员有中国有美国呢？如果中国的运营人员带着自己电脑出差去美国呢？

[msg7086]

@Rocketer 因为中国只有一个时区。你要是告诉他们，有可能有人在不同的时区，怕是能让有些开发的下巴惊掉。

[murmur]

人家就不对国外提供服务啊

[zmcity]

许多国内的厂商根本就没有国际业务，为什么要支持其他时区。

[whypool]

国内厂商做毛线的时区支持，需求阶段压根就不会考虑这个

[opentrade]

@sadfQED2 好像 trip 就是两套

[djs]

国外一样

[HeyWeGo]

关于时区这个概念，我印象最深的是 跨时区参加考试那个电影

[wtdd]

就是没本事外卷，也想不起来外卷，就内卷呗，又不是不能用

[thtznet]

要时区做啥，马上要闭关了，不要浪费资源写这种无用的开发啊。

[lambdaq]

这不跟美国人要求填写 first name last name 一样。。

[littleshy]

@kylix #12 我一直以为是我系统问题，没想到换了新手机还是一样……

[jjwjiang]

按我理解，这个问题无论从哪方面解决都比用纯技术解决成本要低，所以就不用技术去解决了，就这么简单。

[janus77]

跟公司大不大没关系，你在国外没有业务就可以不用做呗

[garipan]

即便是微博这样的公司，境外用户也仍然容易收不到短信，除了成本问题，这事儿更多关乎风控。某种意义上来说，国内很多软件是不欢迎境外用户的，主要就是风险大于收益。

[Sylv]

有的银行 App 也是，手机时区不是中国的话，时差的几小时内发生的交易明细就不显示了，必须要改成中国时间才会显示。

[Biggoldfish]

难道没有国际业务，数据库里就用 string 存时间，进行比较的时候也不用 timestamp 直接 string 比大小？

[DOLLOR]

@darkengine 夏令时真是个恶心的东西，好在越来越多国家开始淘汰了😂

[Jooooooooo]

绑 86 手机号是不是就把你拦住了?

[xuanbg]

时间以+8 区北京时间为准，有问题？
我的前公司，海外业务遍布 6 大洲，照样不需要支持用户乱七八糟的时区。因为用户只要看到的时间是对的就行了。他哪里有这个闲工夫来管你数据库里存的是时间戳还是 UTC ，还是北京时间。。。

[kuaner]

有没有一种可能，其实我们是局域网

[lichdkimba]

可能就是没法测试啊，业务量也小，开发的时候哪会测这些

[ufan0]

@kylix #12 太感谢了，你启发了我！

我在用的某个 APP 不记得什么时候开发无法支持跳转，重装多次无效，半年了，看到这条消息把时间改为 12 小时，就好了。离谱啊。

[xiang0818]

因为墙的原因，就不需要考虑这个事情，有几个国际化的 app ？
不都是分 国际和国外版么

[ofLmvFk]

北京公交 App ，接口应该签名验证必须把手机调成 24 小时才能使用

[systemcall]

因为有墙，要绑+86 手机号
就这 2 点，就可以拦住大部分的海外用户
日服的游戏和那边的一些平台，很多都是正常的。有一些游戏在 Windows 上会乱码，但是这几年的基本上都还好
国内的软件，代码页不是 GBK ，很多都没法使用

[jy28520]

不涉及海外的业务时区其实不重要 我们业务系统的时区都是 GMT+00:00 的 Unix 时间戳 要不然很多的数据直接没法处理了

[securityCoding]

业务涉及时间统一使用 uinxtimestamp ，对外时统一封装 format sdk 就好

[jackma0571]

因为验签呀，你本机时间作为签名一部分，和服务器时间对不上，自然就拦住你的请求了

[wzcloud]

有没有可能，这些应用本身就只是面向国内用户的。。。

[yofly]

平时需求大才会有概念，就像国外的软件到今天还有很多没有 unicode 概念。。。

[Danswerme]

@thtznet 哪里的消息？啥时候闭完啊

[GoodRui]

@kylix 信通院出的通信大数据行程卡 app ，比云闪付可牛逼多了吧？ iOS 上设置 12 小时制，下午晚上就闪退，你说牛逼不牛逼！

[FrankHB]

@julyclyde pacman -Syu 随时升级。
比较麻的是还有一堆副本……类似 mingw-w64-{ucrt-{i686,x86_64}}-{tzdata,ca-certificate}。

[systemcall]

@jackma0571 #67
不用时间戳，非要在那里倒腾字符串，所以出毛病
时间戳不一样可以校验？

[mengzhuo]

正常！还有很多人不知道闰秒，夏令时，NTP

[qeqv]

我特别喜欢研究时区，但是也没见得对找工作有什么用处。以前在公司处理了一大批时区问题，公司业务涉及好几个时区，每个时区的服务器时间问题都是我解决的，也没见得涨工资

[efaun]

大中华局域网不需要 UTC+8 以外的时区

[whileFalse]

没有需求，毕竟欧美程序员都会遇到跨时区问题，而我大中华就是没有这种问题 你说气人不

[julyclyde]

@FrankHB 升级之后还需要重新运行程序才能生效呢
tzdata 是在进程刚启动的时候由 glibc 加载的吧，进程生命周期内不会重加载

[dqzcwxb]

大把用时间戳还觉得比 data time 等时间类型好的人,还美其名曰性能高哈哈哈哈

[jackma0571]

@systemcall 就是说时间戳啊，不在一个时区的话，两个时间戳就是不一样啊

[tutustream]

某些日本手游，说是全球服，但是只有把时间调成日本时区体力才能正常领

[weize888]

想请教一下，像我使用的是 MySQL 数据库，那表字段到底用 datetime 类型，还用 timestamp 类型存储？我以前都是用 bigint 来存 unix 时间戳的。怎么使用比较好？？？

[bthulu]

@Rocketer 中国人太多了, 十几亿人 VS 国外几亿甚至几千万人, 人多性能就捉急, 只能用时间戳应付应付

[bthulu]

@weize888 用 datetime 或者 bigint. timestamp 只有十几年的寿命了

[weize888]

@bthulu 那就继续用这两个。

[flyico]

全国一个时区，根本不需要考虑这个问题好吗？又不是像美国那样 4 个时区

[Akiya]

一个客观的原因是，光美国一个国家就分了多个时区，而中国是一个时区，所以在美国做系统没有办法必须要考虑时区

[FrankHB]

@julyclyde 不是所有的实现都用 glibc ，也不是所有程序对使用过时版本的数据那么敏感（不是彻底错的基本就能用）。
不过一旦涉及到全系统的这些东西确实是有不少破事。我自己做的东西只要有可能就完全不碰这些东西，尽管这些玩意儿至少算是事实标准。