我们什么时候在Timestamp上选择DateTime [英] When do we chose DateTime over Timestamp
问题描述
当我开发Web应用程序越来越精细时，我使用DateTime大部分时间，但有时我不知道是否真的是我想要的。例如，
它发生，我只想显示今天的日期（例如当我想要存储一个论坛或博客帖子），没有计算，没有提供过滤器，没有迭代发生...所以为什么要在 date（）函数中使用 \DateTime ？
我看到这个主题提供了每种技术的优点的一些简单描述。
但是这并不能真正解决问题。在PHP中的DateTime对象和我的数据库中的其他2个字节中丢弃2个字节，因为它允许我使用 DATE_INTERVAL API（在PHP中）是 DateInterval ）和IntlDateFormatter。
此外，这篇文章说，unix_timestamp是从1970年起保留的，但它是不合逻辑，有些测试证明：
echo date（'d / m / Y'，time（-1））;
echoes '31 / 12/1969'！这是合乎逻辑的。 32位无符号int从0到 4 294 967 295 ，68年内只有近二十亿秒，所以int被签名，负时间戳必须存在！
另一个想法对我来说真的很重要，这使我每次都选择DateTime，我想处理日期，而不是整数。 DateTime是一个日期，时间戳不是！我发现时间戳的唯一意义是我想要标记一个文件名的时间，因为在那个cas时间戳是 timestamp ...
然而，这仍然是一个问题：时区处理。
由于MySQL和其他人在将日期存储为DateTime时不处理时区，因此现在，我将TimeZone集成用作过滤器逃逸的转义部分
$ toStoreDate = new \DateTime（$ _ POST ['date']，new DateTimeZone（'UTC'））;
$ dao-> exec（'INSERT INTO mytable（mydate）VALUES（\''。$ toStoreDate->格式（'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'））;
是正确的方法吗？存储一个简单的时间戳，然后获得当地时间是不是更好？
所以，这里是总结以下问题：
- DateTime的另外两个字节在使用API（仅显示）时真的很简单
- 是否放弃unix_timestamp的时候？
- 存储一个简单的时间戳，然后获取当地时间是否更好？
正如在评论中所说，我认为这主要归功于个人喜好。在我看来，使用Unix时间戳和传统非OOP接口不是在今天的世界中前进的方式，例如，我们不使用 INT 数据类型在我们的数据库中以Unix Timestamp格式存储日期，我们应该使用数据库的本机类型，通常是 DATE 或 DATETIME 类型，它与PHP的 DateTime 对象（和其他语言）几乎在本质上与标准转换
详细说明标准转换是什么意思：当您使用MySQL并将值拖回PHP时，您将获得ISO格式的日期字符串，其中在其构造函数中， DateTime 类解析给您一个立即可用的对象。相反，要使用Unix时间戳记路由，您必须使用 strtotime ，然后 date 将其变成您想要的任何格式。
之前我提到过我们的PHP系统和.NET系统之间的互操作。虽然没有使用时间戳导致的具体问题，但根本不是实际的解决方案，因为我们再次使用一个返回可以直接沿管道发送的DateTime值的数据库。如果我们将这个转换为一个unix时间戳，以便在PHP内部使用，那么如果要发送一个响应，或者发送一个响应给.NET应用程序，或者我应该只是说API在这种情况下）这是一个时间戳，并在最后转换它。通过使用 DateTime ，它减轻了任何转换的需要，整个开发过程更容易。
最后添加所有这一切，正如你在发布中也提到的，你可以使用闪亮的项目，如
DateInterval ，更容易的分区，更容易的操作和更容易的格式化等等，当你使用 DateTime ，它是相关的面向对象的合作伙伴犯罪。这只是我眼中更容易的发展过程。 我不相信我最初说是有一个正确的答案，更多的是一个个人基于您自己的编码风格的偏好，上面的评论反映了我的意见。
DateTime的2个字节的数量真的很简单的API（仅显示）
- 我不以为然。特别是PHP脚本通常都是这么短的运行过程。
是时候放弃unix_timestamp ？
是：）
存储一个简单的时间戳，然后获取当地时间是否更好？
请参阅上面的数据库，不是本机为此目的使用Unix Timestamp IMO。您可以调用 - > getTimezone 并将其存储在数据库中，然后使用 - > setTimezone 它再次出来。
As I spend most of my time with php and mysql or pgsql, I will use DateTime as a generic word for the date API. In php there is no "Date", "Time", "DateTime" and "DateTimeOffset"
As I develop web application more and more elaborate, I use DateTime most of time, but sometimes I wonder if it is really what I want.
for example it happens that I just want to display the today's date (for example when I want to store a forum or blog post), there is no calculation, no filter to provide, no iteration to happen... So why do I use \DateTime over the date() function?
I saw this topic that provides some simple description of the pros of each technologies.
But it does not really answer to the question. Is it really a loss to throw up 2 more bytes in a DateTime object in PHP and other 2 bytes in my database as it allows me to use the DATE_INTERVAL API (in php it is DateInterval) and the IntlDateFormatter.
Moreover, this post says that unix_timestamp is reserved from 1970. But it is not logical and some tests prove it :
echo date('d/m/Y',time(-1));
echoes '31/12/1969' ! And it is logical. A 32 bits unsigned int goes from 0 to 4 294 967 295 and there are only almost 2 billions of seconds in 68 years, so the int is signed and "negative timestamp" must exist !
Another think that is really important to me, and that makes me chose DateTime every time is that I want to deal with dates, not with integers. DateTime is a date, timestamp is not ! The only sense that I found to timestamp was the time I wanted to time-mark a filename because in that cas timestamp is timestamp...
However, ther is still a problem : timezone handling. As MySQL and others does not handle timezone when storing dates as DateTime, for now, I use TimeZone integration as the escape part of "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'));
Is it the right way? Wouldn't it be better to store a simple timestamp and then get the good local time?
So, here is a summarise of the question :
- Is the 2 more bytes of DateTime a loss in really simple use of the API (only displaying)
- Is it the time to give up unix_timestamp?
- Wouldn't it be better to store a simple timestamp and then get the good local time?
As said in a comment I believe this is mostly down to personal preference. In my eyes, the use of a Unix timestamp and "legacy" non-OOP interfaces is not the way to do it going forward in today's world, for instance, we don't (read: shouldn't be) using an INT datatype in our database to store dates in Unix Timestamp format, we should instead be using the database's native type which is usually a DATE or DATETIME type which cooperates with PHP's DateTime object (and other languages') almost natively when it comes to standard conversions.
To elaborate a bit on what I mean by standard conversions: When you use MySQL and pull back a value to PHP you get a ISO-formatted date string, of which the DateTime class parses in it's constructor giving you an immediately usable object. In contrast, to go the Unix timestamp route you would have to use strtotime, then date to get it into whatever format you want natively.
I mentioned before about interop between our PHP systems and .NET systems. Whilst there are no specific issues caused by using a timestamp it's simply not the practical solution, as again, we use a database that returns a DateTime value which can be sent straight down the pipe. If we were to convert this to a unix timestamp for use internally in PHP we'd also have to then convert it back out if we were to send a response, or send a response to the .NET Application (or should I just say API in this case) that is a timestamp, and convert it at the end. By using DateTime across the board, it alleviates the need for any conversions to happen whatsoever and the whole development process is easier.
Finally to add to all of this, as you also mentioned in your post, you get to use shiny items such as DateInterval, easier timezoning, easier manipulation and easier formatting etc when you use DateTime and it's related object-oriented partners in crime. It's just an easier development process in my eyes.
I don't believe as I initially said that there is a "correct" answer to this, just more of a personal preference based on your own coding style, and the comments above reflect mine.
Is the 2 more bytes of DateTime a loss in really simple use of the API (only displaying)
- I do not believe so in any way. Especially with PHP scripts generally being such short running processes anyway.
Is it the time to give up unix_timestamp?
Yes :)
Wouldn't it be better to store a simple timestamp and then get the good local time?
See comments above on database, it's not "native" to use a Unix Timestamp for this purpose IMO. You can just call ->getTimezone and store this in the database, then use ->setTimezone when you pull it back out again.
这篇关于我们什么时候在Timestamp上选择DateTime的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
