使用%o ISO-8601年格式解析日期

Question

简述：原作者编写的代码可能存在缺陷。

该代码从我们的提供商接收支付事件，并以 'o-m-d H:i:s' 格式将其记录到数据库中。

这看起来一切顺利，但是 %o 修饰符会在 ISO-8601 周“属于”另一年时给出不同的年份。[参考]

例如，我们有记录为2013-12-31的付款，在正常/非疯狂日期下应为2012-12-31。因此，我们看到的时候似乎发生了未来的付款，有时还发生在过去。

真正的问题在于我无法在 PHP 或 MySQL 中找到任何日期解析函数来解释 %o 标志，从而无法重新格式化这些日期为合理的格式。

是否有人知道如何正确解析这些日期？

- Sammitch

---

2012年12月31日是星期一。根据规则（上周四），这是2013年的第1周。因此，o-m-d将给出形式正确的2013-12-31。但您混合使用了ISO 8601格式化程序和“标准”格式化程序。为什么不使用c作为ISO 8601的完整格式，或者只使用Y-m-d，这将给出2012-12-31？ - Axel Amthor

@AxelAmthor 因为最初编写这个的那个人是个彻头彻尾的白痴。我不知道是什么驱使他去做这件事，但是到处都有“o-m-d”格式。令人震惊的是，他因为无能而被解雇了。 - Sammitch

有人知道如何正确解释这些日期吗？ - 实际上它们已经被正确地解释了。您需要更改您的代码。 - Axel Amthor

@AxelAmthor 是的，它们以“正确”的格式编写，但问题是我无法使 PHP 以相同的格式读取回来，以便我可以添加/减去日期间隔。这些o-m-d格式在这个代码中到处都是，已经有成千上万个使用此格式编写的数据库记录需要我处理。即使我可以只是“更改代码”，我仍然需要能够从o-m-d读取和重新编写日期到Y-m-d，而 PHP 没有一个可以读取它的功能。这就是这个问题的全部意义。 - Sammitch

Answer 1

没有，我不知道。但是，在所有文件中使用 o-m-d 进行 grep，这是一个相当独特的术语，应该可以解决你整个代码库中 98% 的问题。

如果你正在使用版本控制系统（因为你听起来像一个理智的人，所以你可能在使用），那么进行提交、grep（或超级搜索和替换），看看是否对你有更好的效果，如果有，就提交，如果没有，就放弃。就是这么简单。

如果这对你不起作用……嗯……愿上帝怜悯你的灵魂。

- Madara's Ghost