共 3 篇相关文章
这篇讲的是PHP中strtotime函数的一个常见坑点。当开发者使用“-1 month”、“+1 month”或“next month”等相对日期字符串时，结果往往出人意料。比如从2018-07-31执行strtotime("-1 month")，会得到2018-07-01而非预期的2018-06-30，这让人对函数的可靠性产生疑惑。 问题的根因在于strtotime的内部处理逻辑：它先执行月份运算，再对日期进行规范化。以2018-07-31为例，减一月后得到06-31，但6月没有31天，于是日期被自动调整为07-01，就像时间计算中2点60分等于3点一样。文章通过多个代码示例验证了这一原理，例如在2017-08-31上加一月会得到2017-10-01，在2017-01-31上使用next month会跳到2017-03-03，因为2月天数不足导致规范化后月份再进位。 如何解决这个陷阱？作者指出，从PHP5.3版本
这篇文章讲的是开发者在用 xlrd 读取传统 .xls 文件时，常会遇到一个令人困惑的坑：日期和时间格式的单元格被读出来后，并不是预期的可读字符串，而是一串看起来毫无意义的浮点数。作者从这个常见痛点切入，剖析了其根源——Excel 内部是将日期和时间以“序列号”的形式存储的，一个整数部分代表自1900年以来的天数，小数部分则代表一天中的时间比例。因此，直接用 xlrd 的 cell.value 取值，得到的只是这个原始的序列数。 文章的核心价值在于，它不仅解释了这个“为什么”，更给出了明确的“怎么办”。它详细介绍了如何利用 xlrd 自身的 xldate_as_tuple 函数，或者结合 Python 标准库的 datetime 模块，将这些浮点数准确地转换为可用的日期时间对象。对于时间单元格，文章也点明了其本质是小于1的浮点数，需要类似的方法进行转换。通过理解这个机制，开发者就能从容处理 xls 文件中各种格式的日期时间数据，避免在数据预处理阶段被这类问题卡住。
这篇讲的是PHP中一个经典的历史包袱问题——32位Unix时间戳的溢出限制，也就是俗称的“2038年问题”。文章从网上找到的解决方案出发，记下了这个日后可能遇到的坑。 它明确指出，在默认的32位PHP环境中，`date()`、`strtotime()`等函数处理1970年之前或2038年1月19日之后的日期时会出错或得到意外结果，根源就在于时间戳整数溢出。文章不仅点明了这个故障现象，更核心的是梳理了几种可行的应对方案，比如升级到支持64位时间戳的PHP版本，或在代码层面使用`DateTime`类等更现代的API来规避限制。 对于需要处理用户生日、长期规划等场景的开发者来说，提前了解这个边界情况很有必要。作者把这个“可能遇到”的问题提前标记出来，相当于为大家做了一次技术预警和方案预研，避免未来踩坑时手忙脚乱。
