Question

由于我将大部分时间花在php和mysql或pgsql上，我将使用DateTime作为日期API的通用词。在php中没有“Date”，“Time”，“DateTime”和“DateTimeOffset”

随着我开发Web应用程序越来越精细，我大部分时间都使用DateTime，但有时我想知道它是否真的是我想要的。例如，我只想显示今天的日期（例如，当我想存储论坛或博客文章时），没有计算，没有提供过滤器，没有迭代发生...所以我为什么要使用\DateTime功能上的date()？

我看到this topic提供了对每种技术的优点的简单描述。

但它并没有真正回答这个问题。在PHP中的DateTime对象和我的数据库中的其他2个字节中再抛出2个字节真的是一种损失，因为它允许我使用DATE_INTERVAL API（在php中它是DateInterval）和IntlDateFormatter。

此外，这篇文章说unix_timestamp是从1970年开始保留的。但它不符合逻辑，有些测试证明了这一点：

echo date('d/m/Y',time(-1));

'回声'31 / 12/1969'！这是合乎逻辑的。 32位无符号整数从0到4 294 967 295并且在68年内只有近2亿十亿秒，因此int被签名并且“负时间戳”必须存在！

另一个认为这对我来说非常重要，这让我每次选择DateTime都是为了处理日期，而不是整数。 DateTime是一个日期，时间戳不是！我发现时间戳的唯一意义是我想要标记文件名的时间，因为在那个cas时间戳是时间戳......

然而，仍然是一个问题：时区处理。由于MySQL和其他人在将日期存储为DateTime时不处理时区，目前，我使用TimeZone集成作为“过滤出逃出”的转义部分

$toStoreDate = new \DateTime($_POST['date'],new DateTimeZone('UTC'));
$dao->exec('INSERT INTO mytable(mydate) VALUES (\''.$toStoreDate->format('Y-m-d h:i:s').'\')');
$toDisplayDate =new \DateTime( $dao->query('SELECT mydate FROM mytable')
    ->fetch(DAO::FETCH_ASSOC)['mydate']);
$toDisplayDate->setTimeZone(new DateTimeZone('myLocal'));

这是正确的方法吗？存储一个简单的时间戳然后获得当地时间不是更好吗？

所以，这里是对问题的总结：

在简单使用API（仅显示）
是时候放弃unix_timestamp了吗？
存储一个简单的时间戳然后获得当地时间不是更好吗？

Answer 1

正如评论中所述，我认为这主要取决于个人偏好。在我看来，使用Unix时间戳和“遗留”非OOP接口并不是今天在世界上发展的方式，例如，我们不会（读：不应该）使用{{我们数据库中的数据类型以Unix时间戳格式存储日期，我们应该使用数据库的本机类型，它通常是INT或DATE类型，它与PHP的DATETIME对象配合使用（和其他语言'）在标准转换方面几乎是原生的。

详细说明标准转换的含义：当你使用MySQL并将值拉回到PHP时，你会得到一个ISO格式的日期字符串，DateTime类在其中解析它的构造函数给你一个立即可用的对象。相比之下，要使用Unix时间戳路径，您必须使用DateTime，然后 strtotime将其转换为您想要的任何格式。

我之前提到过我们的PHP系统和.NET系统之间的互操作。虽然使用时间戳没有引起任何具体问题，但这并不是实际的解决方案，因为我们再次使用一个返回DateTime值的数据库，该值可以直接发送到管道。如果我们要将它转换为unix时间戳以便在PHP内部使用，那么我们还必须将它转换回来，如果我们要发送响应，或者向.NET应用程序发送响应（或者我应该说API在这种情况下）这是一个时间戳，并在最后转换它。通过全面使用date，它可以减少任何转换发生的需要，并且整个开发过程更加容易。

最后要添加到所有内容中，正如您在帖子中提到的那样，当您使用DateTime时，您可以使用DateInterval等闪亮项目，更轻松的时间更新，更轻松的操作和更轻松的格式化等它是犯罪相关的面向对象的合作伙伴。在我眼里，这只是一个更容易的开发过程。

我不相信，因为我最初说有一个“正确”的答案，更多的是基于你自己的编码风格的个人偏好，上面的评论反映了我的。

对于简单使用API（仅显示）而言，DateTime的另外2个字节是否会丢失

我不相信任何方式。特别是PHP脚本通常都是如此短暂的运行过程。

是时候放弃unix_timestamp了吗？

是的：）

存储简单的时间戳然后获得当地时间不是更好吗？

请参阅上面关于数据库的评论，为此目的使用Unix时间戳IMO并非“原生”。您只需致电DateTime并将其存储在数据库中，然后再次将其重新启用时使用->getTimezone。

Answer 2

不是您问题的准确答案，但我会选择Timestamp而不是DateTime，因为我相信处理Integer值的成本要高得多有效（测量CPU的处理时间），而不是处理DateTime值。

当Numbers Binary Machine Strings而非Objects或Machine时，我感到很舒服。

人与机器

就可理解性而言，我会说当我为计算机编写程序时，我会认为我正在为Performance制作一个程序但是，如果对该层的抽象可以帮助人们更好地理解，为什么我们不在People hate Computers, but they should hate Programmers不成问题时使用它呢？

我不记得是谁或者我在哪里听到的，但有人说// it LOOKS Better $date = new DateTime(); $date->setDate(1986, 3, 24); // March 24, 1986 echo $date->format('Y-m-d'); // it WORKS Better echo date("Y-m-d", mktime(0, 0, 0, 3, 24, 1986)); // March 24, 1986之类的话，我完全同意这一点。因此，作为一个人，我仍然尊重该机器，并将尝试制作更易于理解的计算机程序。：）

<强>更新

为了更好地描绘它，想象我们有一个处理'日期'的程序，每分钟处理10,000次，对吗？

Performance

让我说我每周要查看这段代码一小时，让我们说他们应该在24/7/365处理这些代码，当然我不会处理它，这是一个机器的任务。

顺便说一下，我再说一遍，如果Works不是问题，那么为什么我们不让程序员更容易理解？如果我们需要充分利用它，那么让程序员查看Looks更好的代码，而不是{{1}}！：）

我们什么时候选择DateTime而不是Timestamp

2 个答案: