6

由于我大部分时间都在使用 php 和 mysql 或 pgsql，因此我将使用 DateTime 作为日期 API 的通用词。在 php 中没有“日期”、“时间”、“日期时间”和“日期时间偏移”

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

我看到这个主题提供了对每种技术的优点的一些简单描述。

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

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

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

呼应“1969 年 12 月 31 日”！这是合乎逻辑的。一个 32 位的 unsigned int 从 0 到4 294 967 29568 年只有将近 20 亿秒，所以这个 int 是有符号的，“负时间戳”一定存在！

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

但是，仍然存在一个问题：时区处理。由于 MySQL 和其他人在将日期存储为 DateTime 时不处理时区，所以现在，我使用 TimeZone 集成作为“filter in escape out”的转义部分

$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 时，多 2 个字节的 DateTime 是否会丢失（仅显示）
  • 是时候放弃 unix_timestamp 了吗？
  • 存储一个简单的时间戳然后获取良好的本地时间不是更好吗？
4

2 回答 2

4

正如评论中所说，我相信这主要取决于个人喜好。在我看来，在当今世界使用 Unix 时间戳和“遗留”非 OOP 接口并不是实现它的方式，例如，我们不（阅读：不应该）INT在我们的数据库以 Unix Timestamp 格式存储日期，我们应该改为使用数据库的本机类型，它通常是在标准转换方面几乎原生地与 PHP 的对象（和其他语言）协作的 aDATE或DATETIME类型。DateTime

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

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

最后，添加所有这些，正如您在帖子中提到的那样，您可以在使用时使用闪亮的项目，例如DateInterval更容易的时区、更容易的操作和更容易的格式化等，DateTime并且它是犯罪中相关的面向对象的合作伙伴。在我看来，这只是一个更简单的开发过程。

正如我最初所说的那样，我不相信对此有一个“正确”的答案，更多的是基于您自己的编码风格的个人偏好，上面的评论反映了我的看法。

在真正简单地使用 API 时，多 2 个字节的 DateTime 是否会丢失（仅显示）

  • 我无论如何都不相信。尤其是 PHP 脚本通常都是如此短的运行过程。

是时候放弃 unix_timestamp 了吗？

是的 ：）

存储一个简单的时间戳然后获取良好的本地时间不是更好吗？

请参阅上面关于数据库的评论，为此目的使用 Unix 时间戳不是“本机”IMO。您可以调用->getTimezone并将其存储在数据库中，然后->setTimezone在您再次将其拉出时使用。

于 2012-09-27T11:21:22.643 回答
1

不是您问题的确切答案，但我会选择Timestampover DateTime，因为我相信处理一个Integer值更具成本效益（测量 CPU 的处理时间），而不是处理DateTime值。

当我拥有Numbersa时，我感觉很舒服Binary Machine，而不是拥有Stringsor Objects。

人与机器

就可理解性而言，我会说，当我为计算机编写程序时，我会认为我正在为 aMachine工作，但是如果该层上的抽象可以帮助人类理解更好的是，为什么我们不在Performance不成问题的时候不使用它呢？

我不记得是谁说的或在哪里听到的，但有人说了类似的话People hate Computers, but they should hate Programmers，我完全同意。所以，作为一个人，我仍然尊重那台机器，并将尝试制作更易于计算机理解的程序。:)

更新：

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

// 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 人需要 24/7/365 处理，当然我不会处理这个，这是一个任务机器。

顺便说一句，我要再说一遍，如果Performance不是问题，那为什么我们不让程序员更容易理解呢？如果我们需要充分利用它，那么让程序员更好地查看代码，Works而不是Looks！:)

于 2012-09-27T10:04:52.713 回答