php 获取23 59 59,PHP默认时间为23:59:59 (PHP Default time at 23:59:59)

最新推荐文章于 2025-12-01 09:06:09 发布

转载最新推荐文章于 2025-12-01 09:06:09 发布 · 284 阅读

文章标签：

博客讨论了如何在数据库查询中处理结束时间，特别是如何避免在结束时间上出现精确到午夜的问题。建议在PHP中逻辑处理$enddate，如果时间是午夜则加一天减一秒钟。还提到了MySQL中可以使用INTERVAL操作来指定时间范围，并指出使用'23:59:59'可能存在的毫秒级精度问题和夏令时的影响。

No, there's no real shorthand for specifying that, aside from specifying the literal '23:59:59'.

Seems like the quickest patch is just some PHP logic to reset $enddate before it's sent to your query.

If the time component of $enddate is midnight, then add one day and subtract one second to the value sent to the query.

This does change the specification a bit; it means that specifying an enddate value of '2014-03-19 00:00:00' is equivalent to specifying and enddate value of '2014-03-19 23:59:59', which basically means that it's not possible to specify a sweepstakes ending exactly midnight. But you could end a sweepstakes at time 00:00:01.

In MySQL, we'd typically specify the "end" of a period (like you describe) as midnight of the following day (rather than '23:59:59' of the preceding day), and use a "less than" comparison rather than a "less than or equal to" comparison.

For example:

WHERE mydatetimecol >= '2014-03-19'

AND mydatetimecol < '2014-03-20'

rather than

WHERE mydatetimecol >= '2014-03-19'

AND mydatetimecol <= '2014-03-19 23:59:59'

MySQL does have some handy INTERVAL operations on DATETIME values...

WHERE mydatetimecol >= '2014-03-19'

AND mydatetimecol < '2014-03-19' + INTERVAL 1 DAY

If I absolutely had to "back up" one second, I'd use an interval operation, for example:

WHERE mydatetimecol >= '2014-03-19'

AND mydatetimecol <= '2014-03-19' + INTERVAL 1 DAY + INTERVAL -1 SECOND

Note that some temporal values can actually have milliseconds precision, such as '23:59:59.997' where you could potentially leave a gap between the end of one period and the beginning of another, if you used '23:59:59'.

This isn't really a problem with temporal datatypes stored in MySQL (but other RDMBS such as SQL Server can store fractional seconds). And it's probably not a problem for your particular application (but in the more general case, we typically want for rows to fall into a particular bucket, and not fall between the cracks between the buckets.)

And, I'd be leery of adding 86,399 seconds to a date value, depending on whether the timezone is daylight savings time or not, there's some days that are 23 hours or 25 hours.