场景描述： 在客户APP进行第二轮测试时，发现时间选择器无法滚动选择，滚动后还是会回到默认的第一个时间。开发人员反馈这个是使用组件库组件，于是乎，bug就指向我了。
随后，我在本地浏览器测试、ios 17.0.2 模拟器上测试都是正常运行，一点毛病都没。由于，就信誓旦旦的微信找了测试人员，我测试没有问题。于是就拉会一起演示了下，确实在他手机上有这个情况出现，让他提供了下系统版本号、机型，系统版本： ios14.1，机型：iphone8pro，这老掉牙的机器跟版本，哪还有呀。
无奈😮💨啊，这也只能硬着头皮上了。这又碰上Mac 机器安装了最新的系统版本，没办法再安装14.1的模拟器，这不，找东问西，看看有没有人系统没有升级到最新版本，能帮忙给我远程看下。终于终于，找到一台可以安装的，一顿操作，终于安装好了。
远程调试了下，滚动返回detail确实逻辑没有什么问题，可是可是，一转换就变成了最小值。沿着这个，终于排查到，对日期格式的校验，返回的是false，难不成这个时间格式有问题。由于我又在浏览器的控制台输入了下，new Date('2023-10-10 11:11:11').toString() 额，没问题呢。在14.1的模拟器上一运行，哦哦，返回的是invalid date，好吧好吧。那就确认是new Date 转换的问题了。
网上查了下，确实有这个问题，“# Fix: Invalid date on Safari & IE”，原来在Safari & IE 对日期格式都有要求，并不支持 yyyy-MM-dd 这种格式。而uniapp 打包后的，在新版本没有问题，在老版本确实对js处理日期有限制。
找到问题了，那就解决呗。
结论&解决方案：
重点来了
在new Date('yyyy-MM-dd HH:mm:ss')格式化前需要先把字符串转化为Safari、IE支持的格式，可以是yyyy/MM/dd HH:mm:ss或yyyy-MM-ddTHH:mm:ss或其他。
const fixDateForAllBrowsers = dateString => dateString.replace(/-/g, '/');
反馈给测试人员，重新安装下包，解决！！哦耶✌️
